If my memory serves me correctly, lads over at SETI found out that there's no difference in speed between 32 and 64 bit app if same set of compiler flags used.
As the one who did the port of the SETI classic client to AMD64, it was about 15% faster when used along with AMD64 optimized math routines, then available only in SUSE distros. In other distros without such routines, it was in the same ballpark as the x86 client.
I won't even comment on your statement that more registers don't matter in an FPU-intensive application.
On Seti they have found that using the 32 bit code compiled with the Intel compiler gives the best results for all cpu's, irrespective of wether the cpu's are 32 or 64 bit and Intel or AMD.
The only problem is the Intel Compiler, and the relevant maths libaries are expensive, and that is also a yearly cost. Most of the Projects are running on small budgets and have better uses for their funds.
So if you are convinced you can produce better faster code that validates go ahead, the projects would appreciate your input. From all the correspondence I have seen, especially on the Seti site, I personally don't think a 64 bit version will achieve anything, probably the reverse.
Here a lot of the optimisation has been done by Akos, who does his work at assembler level.
On Seti they have found that using the 32 bit code compiled with the Intel compiler gives the best results for all cpu's, irrespective of wether the cpu's are 32 or 64 bit and Intel or AMD.
Andy
Hi,
i do not know who found that out but it's not quite true.
The 64bit apps of S@H enhanced were 10% faster than the 32bit apps.
Regardless of our disputes here, I think that at least partial support for platform name x86_64-unknown-linux-gnu (and it's variant x86_64-pc-linux-gnu) should exist. Partial in sense that if server encounters client host of that platform, it returns client software for platform named i686-pc-linux-gnu.
Bruce, Bernd, is it too much for us to expect such a support? Until then, we'll have to fiddle with app_info.xml to run official binary :(
Regardless of our disputes here, I think that at least partial support for platform name x86_64-unknown-linux-gnu (and it's variant x86_64-pc-linux-gnu) should exist. Partial in sense that if server encounters client host of that platform, it returns client software for platform named i686-pc-linux-gnu.
Bruce, Bernd, is it too much for us to expect such a support? Until then, we'll have to fiddle with app_info.xml to run official binary :(
I understand. However, this is a tradeoff.
Running 32 bit binaries on a 64 bit Linux requires certain libraries, the presence of which is not e.g. reported by the Client. The benefit from having this partial support would be an easier installation for people who have this libraries installed, but the downside would be lots of Client Errors from machines which haven't, without giving useful error messages to the users.
We'll consider this. Given the increasing number of these machines I will probably make a native 64 bit App in the near future, which should be the cleanest way. For now I'd like to point you to the 4.16 App on the Power User Apps page. It comes with a working app_info.xml (I think that the 4.16 was slightly faster on some AMDs than 4.17, am I correct?).
For most users, I think, the use of the official 32 bit BOINC Core Client that reports the official platform would be the easiest way, though I am aware of that this prevents optimal crunching on the (few) projects that supply a native 64 bit Linux App.
Yes the 4.16 is quietly faster then the 4.17 on Pentium M, Xeon and Tualatin P3.
I would prefer a Win64 executable too. This is probably only for a minority of all Einstein user, but that will change in addition.
So far, two projects have added support for x86-64: SETI sends the x86 application and SIMAP a true x86-64 application. Would you consider supporting x86_64-pc-linux-gnu or x86_64-unknown-linux-gnu similarly?
Chess960 now supports AMD64 with a native Linux application and HashClash with a 32-bit Linux application...
So far, two projects have added support for x86-64: SETI sends the x86 application and SIMAP a true x86-64 application. Would you consider supporting x86_64-pc-linux-gnu or x86_64-unknown-linux-gnu similarly?
Chess960 now supports AMD64 with a native Linux application and HashClash with a 32-bit Linux application...
HashClash now supports AMD64 on Windows with a 32-bit application...
FWIW, running two instances of the client, one the 32-bit client, the other, the 64-bit client, on the same 4-core system, but limiting each client to 2 cores, I can compare the relative performance of 32-bit and 64-bit SIMAP's HMMER: the 64-bit version is about 7% faster.
By enabling vectorization (supported by default on AMD64), the SIMAP developers observed other 8% improvement.
Bottom line: porting the project application to AMD64 has the potential to improve performance by 15%!
So far, two projects have added support for x86-64: SETI sends the x86 application and SIMAP a true x86-64 application. Would you consider supporting x86_64-pc-linux-gnu or x86_64-unknown-linux-gnu similarly?
Chess960 now supports AMD64 with a native Linux application and HashClash with a 32-bit Linux application...
HashClash now supports AMD64 on Windows with a 32-bit application...
Guess what? Leiden Classical now supports AMD64 on Linux with a 32-bit application. ;-)
RE: If my memory serves me
)
As the one who did the port of the SETI classic client to AMD64, it was about 15% faster when used along with AMD64 optimized math routines, then available only in SUSE distros. In other distros without such routines, it was in the same ballpark as the x86 client.
I won't even comment on your statement that more registers don't matter in an FPU-intensive application.
On Seti they have found that
)
On Seti they have found that using the 32 bit code compiled with the Intel compiler gives the best results for all cpu's, irrespective of wether the cpu's are 32 or 64 bit and Intel or AMD.
The only problem is the Intel Compiler, and the relevant maths libaries are expensive, and that is also a yearly cost. Most of the Projects are running on small budgets and have better uses for their funds.
So if you are convinced you can produce better faster code that validates go ahead, the projects would appreciate your input. From all the correspondence I have seen, especially on the Seti site, I personally don't think a 64 bit version will achieve anything, probably the reverse.
Here a lot of the optimisation has been done by Akos, who does his work at assembler level.
Andy
RE: On Seti they have found
)
Hi,
i do not know who found that out but it's not quite true.
The 64bit apps of S@H enhanced were 10% faster than the 32bit apps.
Regardless of our disputes
)
Regardless of our disputes here, I think that at least partial support for platform name x86_64-unknown-linux-gnu (and it's variant x86_64-pc-linux-gnu) should exist. Partial in sense that if server encounters client host of that platform, it returns client software for platform named i686-pc-linux-gnu.
Bruce, Bernd, is it too much for us to expect such a support? Until then, we'll have to fiddle with app_info.xml to run official binary :(
Metod ...
RE: Regardless of our
)
I understand. However, this is a tradeoff.
Running 32 bit binaries on a 64 bit Linux requires certain libraries, the presence of which is not e.g. reported by the Client. The benefit from having this partial support would be an easier installation for people who have this libraries installed, but the downside would be lots of Client Errors from machines which haven't, without giving useful error messages to the users.
We'll consider this. Given the increasing number of these machines I will probably make a native 64 bit App in the near future, which should be the cleanest way. For now I'd like to point you to the 4.16 App on the Power User Apps page. It comes with a working app_info.xml (I think that the 4.16 was slightly faster on some AMDs than 4.17, am I correct?).
For most users, I think, the use of the official 32 bit BOINC Core Client that reports the official platform would be the easiest way, though I am aware of that this prevents optimal crunching on the (few) projects that supply a native 64 bit Linux App.
BM
BM
Yes the 4.16 is quietly
)
Yes the 4.16 is quietly faster then the 4.17 on Pentium M, Xeon and Tualatin P3.
I would prefer a Win64 executable too. This is probably only for a minority of all Einstein user, but that will change in addition.
RE: So far, two projects
)
Chess960 now supports AMD64 with a native Linux application and HashClash with a 32-bit Linux application...
RE: RE: So far, two
)
HashClash now supports AMD64 on Windows with a 32-bit application...
FWIW, running two instances
)
FWIW, running two instances of the client, one the 32-bit client, the other, the 64-bit client, on the same 4-core system, but limiting each client to 2 cores, I can compare the relative performance of 32-bit and 64-bit SIMAP's HMMER: the 64-bit version is about 7% faster.
By enabling vectorization (supported by default on AMD64), the SIMAP developers observed other 8% improvement.
Bottom line: porting the project application to AMD64 has the potential to improve performance by 15%!
RE: RE: RE: So far, two
)
Guess what? Leiden Classical now supports AMD64 on Linux with a 32-bit application. ;-)