Couldn't agree more Augustine - it's bloody annoying having to create app_info's, but it's better than having the box sit idle.
But that's not the alternative when there are projects such as SIMAP, Chess960, ABC ß, SETI & SETI ß, HashClash, Leiden, Malaria and Docking that do support AMD64 clients. ;-)
As I said
Quote:
The best solution though is for the project to support the growing number of 64bit crunchers.
The best solution though is for the project to support the growing number of 64bit crunchers.
As I see it, it's this project's loss: my 5 Linux systems, totaling 12 cores, run the 64-bit client and don't contribute to Einstein, only a couple of single-core Windows system do.
I'll add my name to the petition for 64bit linux support.
I'll add my name too :-)
Now I use app_info.xml but it is not the best way. I agree with Augustine, setting server to send the x86 application to x86-64 clients is easiest and I guess a lot of 64b linux machine will be attached to the project.
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. ;-)
Yay! Malaria now supports AMD64 on Linux with a 32-bit application too.
ABC ß now provides a 64-bit application for AMD64 on Linux yielding double the performance.
Docking just added support for AMD64 Linux clients through a 32-bit application for the time being.
RieselSieve is yet another project supporting AMD64 Linux clients by sending the 32-bit 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...
Guess what? Leiden Classical now supports AMD64 on Linux with a 32-bit application. ;-)
Yay! Malaria now supports AMD64 on Linux with a 32-bit application too.
ABC ß now provides a 64-bit application for AMD64 on Linux yielding double the performance.
Docking just added support for AMD64 Linux clients through a 32-bit application for the time being.
RieselSieve is yet another project supporting AMD64 Linux clients by sending the 32-bit application.
RieselSieve supports AMD64 Windows clients by sending the 32-bit application too.
there is NO, Zero, Zip, Nada benefit to a 64 bit einstien app, and one penalty from using it. A 64 bit cpu does two things differently: Tt provides 64 bit integer support, this is useless for einstien and most other boinc projects because they use floating point arithmatic instead. It also provides 64bit memory addressing. This is useless unless you need more than 4gig of memory. Einstien doesn't, and afaik the only project that might need it it reasonable nearterm (next few years) future is CPDN. For apps that don't need 64bit memory addressing using it slows them down since all the memory addresses (used for the if/elses, loops, function calls, etc) are now twice as big and require twice as much cache to store, and twice as much memory bandwidth to copy from the cache to main memory (and vice versa).
I know this is an old post, but you are so wrong I hate to leave it.
64-bit mode does *NOT* automatically double everything. In fact, in many cases the code ends up smaller, and you can often use short jumps and use *less* bandwidth than 32-bit code. In the end it depends on your application and compiler, but over all 64-bit apps are faster on x86.
The increased number of registers and the use of SIMD instead of the ancient and broken 387 FPU should make einstein perform better.
The 387 was never a good FPU, and 64-bit x86 disables it. Future 64-bit x86 CPUs will not even have a 387 FPU in them.
I think the lack of a 64-bit version is mostly pragmatic.
I'm not sure if they made it into the official version, but Akos was experimenting with hotloops that used both SSE and 387 instructions to process data in parallel. If they were put into the deployed version, disabling the 387 would be a significant performance hit for an x86-64 native app.
As WCG uses HTTPS in the communications with the client, a file with public encryption keys is needed. Download this new x86-64 Linux client, still version 5.8.11, boinc_5.8.11_x86_64-pc-linux-gnu.tgz and copy all the files in the tar-ball to your system's working BOINC directory.
RE: RE: Couldn't agree
)
As I said
:)
RE: The best solution
)
As I see it, it's this project's loss: my 5 Linux systems, totaling 12 cores, run the 64-bit client and don't contribute to Einstein, only a couple of single-core Windows system do.
RE: I'll add my name to the
)
I'll add my name too :-)
Now I use app_info.xml but it is not the best way. I agree with Augustine, setting server to send the x86 application to x86-64 clients is easiest and I guess a lot of 64b linux machine will be attached to the project.
RE: RE: RE: RE: Quote
)
RieselSieve is yet another project supporting AMD64 Linux clients by sending the 32-bit application.
RE: RE: RE: RE: Quote
)
RieselSieve supports AMD64 Windows clients by sending the 32-bit application too.
I'm happy to see that several
)
I'm happy to see that several projects have started this week to support AMD64. Here's an updated list:
* Chess960 (Linux)
* ABC ß (Linux)
*
Predictor (Linux)
* 32-bit Application Sent to AMD64 Clients
* HashClash (Linux & Windows)
* Leiden (Linux)
* Malaria (Linux)
* Docking (Linux)
* RieselSieve (Linux & Windows)
*
WCG (Linux soon)
FYI, the new x86-64 Linux
)
FYI, the new x86-64 Linux client, version 5.8.11, can be found at boinc_5.8.11_x86_64-pc-linux-gnu.gz. Again, the x64 Windows client, version 5.4.11, by Crunch3r, at boinc_5.4.11_windows_amd64.zip.
For more information, see BoincStats Forum.
HTH
RE: there is NO, Zero, Zip,
)
I know this is an old post, but you are so wrong I hate to leave it.
64-bit mode does *NOT* automatically double everything. In fact, in many cases the code ends up smaller, and you can often use short jumps and use *less* bandwidth than 32-bit code. In the end it depends on your application and compiler, but over all 64-bit apps are faster on x86.
The increased number of registers and the use of SIMD instead of the ancient and broken 387 FPU should make einstein perform better.
The 387 was never a good FPU, and 64-bit x86 disables it. Future 64-bit x86 CPUs will not even have a 387 FPU in them.
I think the lack of a 64-bit version is mostly pragmatic.
I'm not sure if they made it
)
I'm not sure if they made it into the official version, but Akos was experimenting with hotloops that used both SSE and 387 instructions to process data in parallel. If they were put into the deployed version, disabling the 387 would be a significant performance hit for an x86-64 native app.
RE: FYI, the new x86-64
)
As WCG uses HTTPS in the communications with the client, a file with public encryption keys is needed. Download this new x86-64 Linux client, still version 5.8.11, boinc_5.8.11_x86_64-pc-linux-gnu.tgz and copy all the files in the tar-ball to your system's working BOINC directory.
For more information, see BoincStats Forum.
HTH