Einstein@Home for 64-bit Linux on AMD Athlon 64 X2

And therein lies the problem. There is no 64 bit Einstein application. So you need to install at least the 32 bit libraries. If you do not take advantage of 64 bit features, like more that 4 GB RAM, I suggest you install the 32 bit OS. And don't forget to install the SMP kernel!

Michael

PS: Welcome to Team 'Linux Users Everywhere', Jure Repinc and RenaudKener.

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 did compile BOINC for AMD64 natively. My box runs AMD64 port of Debian Etch, so by default no 32 bits there. The binary is fine, however:

• * benchmark figures (which almost don't matter anymore) are quite similar to those of self-compiled 32-bit version
  * BOINC CC doesn't take much of CPU time anyhow - science app does (Einstein in our case)
  * if you configure/compile BOINC without any twisting, it'll report architecture as linux-amd64 ... which means you're forced to use

anonymous platform tweaks
All in all, it's just not worth it.

64-bit applications can benefit from more registers and better calling conventions. Typically, 64-bit applications have smaller code-size and are faster because of fewer register spills. On some OS, optimized math routines also improve the performance over legacy x87 code.

This has been discused gazillion times already. Most of at least somehow optimized (32-bit) apps already use any kind of vector maths (SSE, SSE2, 3Dnow!, MMX) so 64-bit version won't bring any benefit here. Additional number of registers would bring some gain if the science apps would be more general apps. Longer registers would bring some gain if app did a lot of long integer (64 bit) arithmetics. As most of science apps tend to be FPU (or SSE if you want) intensive, gain of useing additional registers (to avoid too many register to memory transfers) is neglectible.

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. Some even reported that 64-bit app seems marginally slower. Which makes sense: in certain circumstances code is actually larger as you need to use 64-bit address space. In addition to that you need to push/pop a bit more data to stack and there are other little tidbits.

Face it, with current generation of AMD64-class processors, there's no big advantage to use 64 bit programmes unless a particular app needs to use more than 2 Gigabytes of memory. There's a lot more sense in running 64-bit OS though.
Please note that running 32-bit apps on AMD64 platform does not mean running them in any kind of emulator which would bring additional overhead and thusly a slow-down. It is somehow similar to ECOFF support in linux/alpha, which enables you to (natively) run OSF1 (Digital Unix) binaries under Linux - it nearly always meant getting considerable speedup comapred to running native Linux binaries as there was no emulation - just ability to run slightly differently formed executables and shared libraries.

Remark: above I'm referring to AMD64 platform. With that I'm referring both to 64-bit AMD processors as well as Intel processors with EM64T extensions.