curious performance enhancement or punishment?

ML1
ML1
Joined: 20 Feb 05
Posts: 339
Credit: 67,484,017
RAC: 38,469

RE: ... I think a native 64

Message 85950 in response to message 85949

Quote:
... 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.)

Happy crunchin',
Martin

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

Huff
Huff
Joined: 5 Jan 06
Posts: 36
Credit: 1,378,476
RAC: 0

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??

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3,516
Credit: 470,709,176
RAC: 54,212

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

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3,516
Credit: 470,709,176
RAC: 54,212

RE: The issue isn't that

Message 85953 in response to message 85950

Quote:


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?

CU
Bikeman

ML1
ML1
Joined: 20 Feb 05
Posts: 339
Credit: 67,484,017
RAC: 38,469

RE: ... Just out of

Message 85954 in response to message 85953

Quote:
... Just out of interest, why wouldn't you want to use a 32 bit app on your 64 bit machine?


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)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.