"Just" observations always has me scratch my head when it comes this type of software and the wide choice of libraries that needs to be picked from to get the optimal performance. VINA 4.2.x is already scheduled to be implemented at WCG, and as I understand it first for a new project at WCG [don't ask for noone will tell], then FAAH will follow sometime later when WCG and scientists are happy and experienced with this new version. Also it was shared that all new applications would be ported to 64 bit, so it is more than probable this applies to the FAAH VINA roll out too. When?: Twist my arm and still would not spill :D

On 64 bit being faster we have now actual data: For the individual 64 bit machines running C4CW 6-8% on average... few reported actual slower times. Project wide impact about 3% shorter run times, suggesting that less than half have 64 bit enabled device.

Also, multiple times mentioned, for those who did not know already, you only need to have a 64 bit OS. If the client (BOINC) is 6.10 (WCG continues to recommend 6.10.58), you're still getting any available 64 bit science apps... fully automated, which is a good reason why WCG only has a 32 bit custom package. Notably though, "pure" 64 bit systems that can't be enabled to do 32 bit emulation, would need to fetch the 64 bit client at Berkeley. Not seen them mentioned on the forums, but it seems that techs are observing those trying to connect to this grid.

--//--

PS: The Forum search function actually works ;-)

edit: inserted indicated version number.

.

It does work. On another boinc project my 64-bit linux machine received about 80 tasks each of 32 and 64 bit. Since the 64-bit was about 20% faster, after those initial 80 each, the server only issued 64-bit work resulting in a ratio of 400 vs. 0 until an application version change started the comparison process again.

Much from the acceleration on 64 bit platforms comes from SSE instructions. One needs to be careful, though, since those are true 64 bit float representations while on the 32 bit platform the physical storing may be indeed 32 bits wide, but as long as values are kept in the registers, it is 80 bits wide. Ouch. A consequence is that results from true 32 bit executables and true 64 bit executables may differ ... Let's not press them too much. It all needs testing ... and ... after all ... the true bottleneck is the the wet lab.

This comes from the gcc man page, so we one can switch this off:

-mfpmath=unit
Generate floating point arithmetics for selected unit unit. The choices for unit are:

`387'
Use the standard 387 floating point coprocessor present majority of chips and emulated otherwise. Code compiled with this option will run almost everywhere. The temporary results are computed in 80bit precision instead of precision specified by the type resulting in slightly different results compared to most of other chips. See -ffloat-store for more detailed description.

This is the default choice for i386 compiler.
`sse'
Use scalar floating point instructions present in the SSE instruction set. This instruction set is supported by Pentium3 and newer chips, in the AMD line by Athlon-4, Athlon-xp and Athlon-mp chips. The earlier version of SSE instruction set supports only single precision arithmetics, thus the double and extended precision arithmetics is still done using 387. Later version, present only in Pentium4 and the future AMD x86-64 chips supports double precision arithmetics too.

For the i386 compiler, you need to use -march=cpu-type, -msse or -msse2 switches to enable SSE extensions and make this option effective. For the x86-64 compiler, these extensions are enabled by default.

The resulting code should be considerably faster in the majority of cases and avoid the numerical instability problems of 387 code, but may break some existing code that expects temporaries to be 80bit.

This is the default choice for the x86-64 compiler.