... I think a native 64 bit app would be worth a try if it gave you a 10%+ performance increase (personal opinion)...
I would expect a small performance increase if only for the sake of the compiler being able to use more CPU registers...
The issue isn't that of a (large) performance increase 'justifying' a 64-bit client. It is rather more of getting the client to run on 64-bit systems in the first place.
You'll get a fair few more machines on your list if you did have a native 64-bit client... Optimised or not. (If only from myself.)
There is not that much influence of the distro wrt. performance or reliability for BOINC. The one thing that comes to my mind when talking about Suse 10.1 is this kerry/beagle Desktop indexing thing. It's installed by default and will speed up finding data on your computer by indexing documents in the background, but this background activity is consuming quite a lot of CPU resources especially on not so new hardware. Unless you feel you really need it, from a BOINC point-of-view it's better to de-installl kerry-beagle.
The issue isn't that of a (large) performance increase 'justifying' a 64-bit client. It is rather more of getting the client to run on 64-bit systems in the first place.
You'll get a fair few more machines on your list if you did have a native 64-bit client... Optimised or not. (If only from myself.)
Agreed. But if the native app is installed by default on all 64 bit hosts, it really must be at least as fast as the 32 bit app, and it should not further widen the gap between Intel and AMD CPUs. That's no trivial thing to do, the gcc compiler can optimize code for the Pentium III and Pentium M for 32 bit code for quite some time now, but for 64 bit code, only relatively recent versions of gcc can optimize for Core2. Code optimized for AMD'S K8 seems to be quite slow on Core2. So basically you want to use a faily recent gcc, which has compatibility issues with older libs that are present on older Linux distros and kernels, even when building statically linked binaries.
Just out of interest, why wouldn't you want to use a 32 bit app on your 64 bit machine?
RE: ... I think a native 64
)
I would expect a small performance increase if only for the sake of the compiler being able to use more CPU registers...
The issue isn't that of a (large) performance increase 'justifying' a 64-bit client. It is rather more of getting the client to run on 64-bit systems in the first place.
You'll get a fair few more machines on your list if you did have a native 64-bit client... Optimised or not. (If only from myself.)
Happy crunchin',
Martin
See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)
I have the SUSE 10.1 flavor.
)
I have the SUSE 10.1 flavor. Would this be a good distro to use for E@H??
There is not that much
)
There is not that much influence of the distro wrt. performance or reliability for BOINC. The one thing that comes to my mind when talking about Suse 10.1 is this kerry/beagle Desktop indexing thing. It's installed by default and will speed up finding data on your computer by indexing documents in the background, but this background activity is consuming quite a lot of CPU resources especially on not so new hardware. Unless you feel you really need it, from a BOINC point-of-view it's better to de-installl kerry-beagle.
CU
Bikeman
RE: The issue isn't that
)
Agreed. But if the native app is installed by default on all 64 bit hosts, it really must be at least as fast as the 32 bit app, and it should not further widen the gap between Intel and AMD CPUs. That's no trivial thing to do, the gcc compiler can optimize code for the Pentium III and Pentium M for 32 bit code for quite some time now, but for 64 bit code, only relatively recent versions of gcc can optimize for Core2. Code optimized for AMD'S K8 seems to be quite slow on Core2. So basically you want to use a faily recent gcc, which has compatibility issues with older libs that are present on older Linux distros and kernels, even when building statically linked binaries.
Just out of interest, why wouldn't you want to use a 32 bit app on your 64 bit machine?
CU
Bikeman
RE: ... Just out of
)
I simply haven't installed the few hundred MBytes of 32-bit libs that duplicate the functionality of the 64-bit libs.
On servers, that is very good for minimising the exposure to failure. It also reduces installation dependencies.
Happy crunchin',
Martin
See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)