but then, if the obvious explanation for the bad performance of the einstein/linux application is not correct, what is the correct one ?
In a Linux environment, I get the following picture :
-----------------------------------------------------
$ ls -l ein*
-rwx------ 1 roger roger 1697218 2005-03-16 01:17 einstein_4.80_i686-pc-linux-gnu
-rw------- 1 roger roger 923679 2005-03-16 01:16 einstein_4.80_i686-pc-linux-gnu.so
(kami)roger:/ligo/boinc/BOINC/projects/einstein.phys.uwm.edu
$ file ein*gnu
einstein_4.80_i686-pc-linux-gnu: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.30, dynamically linked (uses shared libs), not stripped
(kami)roger:/ligo/boinc/BOINC/projects/einstein.phys.uwm.edu
$ ldd ein*gnu
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7fdb000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7fb8000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7fa8000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e74000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fea000)
(kami)roger:/ligo/boinc/BOINC/projects/einstein.phys.uwm.edu
$
-----------------------------------------------------
So, it appears that libm (from glibc) is involved. Note that this particular libm is from the debian libc6-i686 package, which supports AMD Athlon/Opteron among others. Back then, I thought that being able to move over to a pure (AMD) 64-bit environnment might do some good, after all (?). A factor of nearly two in benchmark figures for a native linux and native windows application needs a convincing explanation.
Until then, I run einstein_4.79_windows_intelx86.exe in a niced-down wine environment, with good performance - no screen savers. And boinc 4.19 has been rather stable, too.
Now that I have a production copy of XP x64 I would like to second the request for both a x64 bonic app and request a x64 science app.
Understood.
I am curious. Do the exising 32-bit BOINC app and existing 32-bit Einstein@Home application not run on your system? Or do they run, but you'd like an app that makes better use of the OS and hardware?
I am curious. Do the exising 32-bit BOINC app and existing 32-bit Einstein@Home application not run on your system? Or do they run, but you'd like an app that makes better use of the OS and hardware?
I think he asks for a science app which makes use of the new hardware.
Just recompiling for x68-64 could make the app faster. There
is no need for 64 bit address space, but AMDs 64 bit processors provide
more registers, so there is a chance for a speed increase. (AFAIK)
Needs to be tested though...
As I am planning to buy an AMD X2 I would be very interested in
the performance of an 64 bit einstein app.
64 bit core client would make no much sense, because there is
no real computation done.
The existing apps bonic 4.45 & einstein 4.79 appear to work the same under XP x64 as they did under the 32 bit version. I simply hope to crunch more wus by taking advantage of the hardware. Michael may be right about the bonic app but small improvements build up over time.
If you need a tester I am willing.
The tests that I have seen show only a modest improvement at best, in some cases even a reduction. This may change when enough 64bit applications are out there for the machine to run completely in 64bit mode. However even then the overhead may outweight the benifits if the program does not really need the additional bits.
Do not let this statment mislead you I do think it should be done, however I don't think it will make as big a difference as people think. And it needs to be added as a platform so that when there are computers running full time in 64 bit mode BOINC will not be the program that prevents this.
Depends on the aplication...
For example Cinebench from Cinema 4D provides about +20% performance boost...on Intel. I do consider 64-bit solution from Intel (Pentium D or single-cored Presshot) far from ideal and would expect AMD64 doing better.
Some 64-bit apps can be even slower on Intel and you can 2x+ boots on some 64-bit apps on AMD64.
As a first step, I would rather put energy to 32-bit optimalization of Einstein. Reason?
1. we can possibly get more than +20% - see optimalized SETI
2. all Einstein users may immediately benefit from such an optimalization.
I also do think it should be done (all my 3 home boxes are Intel or AMD dual-cored 64-bits), but after 32-bit optimalization is in place.
The reasons the 64 bit application does not do much better over the 32 bit is because the work is mostly done in the FPU. The FPU has not changed significantly enough in the 64 bit processors to make a huge difference. Yes the larger L2 cache can help, but that's all.
Now if they increased the FPU bit size, that could make a huge difference.
32 bit subsystem:
Running CPU benchmarks
2005-12-02 13:48:21 [---] Benchmark results:
2005-12-02 13:48:21 [---] Number of CPUs: 1
2005-12-02 13:48:21 [---] 1105 double precision MIPS (Whetstone) per CPU
2005-12-02 13:48:21 [---] 2100 integer MIPS (Dhrystone) per CPU
2005-12-02 13:48:21 [---] Finished CPU benchmarks
64-bit subsystem (recompiled):
2005-12-02 13:23:53 [---] Running CPU benchmarks
2005-12-02 13:24:51 [---] Benchmark results:
2005-12-02 13:24:51 [---] Number of CPUs: 1
2005-12-02 13:24:51 [---] 1664 double precision MIPS (Whetstone) per CPU
2005-12-02 13:24:51 [---] 4046 integer MIPS (Dhrystone) per CPU
2005-12-02 13:24:51 [---] Finished CPU benchmarks
Maybe I'm doing sth wrong, but...
having 64-bit binaries for linux would be nice.
You're right
)
You're right GentleGiant,
but then, if the obvious explanation for the bad performance of the einstein/linux application is not correct, what is the correct one ?
In a Linux environment, I get the following picture :
-----------------------------------------------------
$ ls -l ein*
-rwx------ 1 roger roger 1697218 2005-03-16 01:17 einstein_4.80_i686-pc-linux-gnu
-rw------- 1 roger roger 923679 2005-03-16 01:16 einstein_4.80_i686-pc-linux-gnu.so
(kami)roger:/ligo/boinc/BOINC/projects/einstein.phys.uwm.edu
$ file ein*gnu
einstein_4.80_i686-pc-linux-gnu: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.30, dynamically linked (uses shared libs), not stripped
(kami)roger:/ligo/boinc/BOINC/projects/einstein.phys.uwm.edu
$ ldd ein*gnu
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7fdb000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7fb8000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7fa8000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e74000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fea000)
(kami)roger:/ligo/boinc/BOINC/projects/einstein.phys.uwm.edu
$
-----------------------------------------------------
So, it appears that libm (from glibc) is involved. Note that this particular libm is from the debian libc6-i686 package, which supports AMD Athlon/Opteron among others. Back then, I thought that being able to move over to a pure (AMD) 64-bit environnment might do some good, after all (?). A factor of nearly two in benchmark figures for a native linux and native windows application needs a convincing explanation.
Until then, I run einstein_4.79_windows_intelx86.exe in a niced-down wine environment, with good performance - no screen savers. And boinc 4.19 has been rather stable, too.
-rg-
Now that I have a production
)
Now that I have a production copy of XP x64 I would like to second the request for both a x64 bonic app and request a x64 science app.
RE: Now that I have a
)
Understood.
I am curious. Do the exising 32-bit BOINC app and existing 32-bit Einstein@Home application not run on your system? Or do they run, but you'd like an app that makes better use of the OS and hardware?
Director, Einstein@Home
RE: I am curious. Do the
)
I think he asks for a science app which makes use of the new hardware.
Just recompiling for x68-64 could make the app faster. There
is no need for 64 bit address space, but AMDs 64 bit processors provide
more registers, so there is a chance for a speed increase. (AFAIK)
Needs to be tested though...
As I am planning to buy an AMD X2 I would be very interested in
the performance of an 64 bit einstein app.
64 bit core client would make no much sense, because there is
no real computation done.
Team Linux Users Everywhere
The existing apps bonic 4.45
)
The existing apps bonic 4.45 & einstein 4.79 appear to work the same under XP x64 as they did under the 32 bit version. I simply hope to crunch more wus by taking advantage of the hardware. Michael may be right about the bonic app but small improvements build up over time.
If you need a tester I am willing.
The tests that I have seen
)
The tests that I have seen show only a modest improvement at best, in some cases even a reduction. This may change when enough 64bit applications are out there for the machine to run completely in 64bit mode. However even then the overhead may outweight the benifits if the program does not really need the additional bits.
Do not let this statment mislead you I do think it should be done, however I don't think it will make as big a difference as people think. And it needs to be added as a platform so that when there are computers running full time in 64 bit mode BOINC will not be the program that prevents this.
BOINC WIKI
BOINCing since 2002/12/8
Depends on the
)
Depends on the aplication...
For example Cinebench from Cinema 4D provides about +20% performance boost...on Intel. I do consider 64-bit solution from Intel (Pentium D or single-cored Presshot) far from ideal and would expect AMD64 doing better.
Some 64-bit apps can be even slower on Intel and you can 2x+ boots on some 64-bit apps on AMD64.
As a first step, I would rather put energy to 32-bit optimalization of Einstein. Reason?
1. we can possibly get more than +20% - see optimalized SETI
2. all Einstein users may immediately benefit from such an optimalization.
I also do think it should be done (all my 3 home boxes are Intel or AMD dual-cored 64-bits), but after 32-bit optimalization is in place.
The reasons the 64 bit
)
The reasons the 64 bit application does not do much better over the 32 bit is because the work is mostly done in the FPU. The FPU has not changed significantly enough in the 64 bit processors to make a huge difference. Yes the larger L2 cache can help, but that's all.
Now if they increased the FPU bit size, that could make a huge difference.
BOINC client benchmark
)
BOINC client benchmark (linux):
Processor: 1 AuthenticAMD Mobile AMD Athlon(tm) 64 Processor 3400+
32 bit subsystem:
Running CPU benchmarks
2005-12-02 13:48:21 [---] Benchmark results:
2005-12-02 13:48:21 [---] Number of CPUs: 1
2005-12-02 13:48:21 [---] 1105 double precision MIPS (Whetstone) per CPU
2005-12-02 13:48:21 [---] 2100 integer MIPS (Dhrystone) per CPU
2005-12-02 13:48:21 [---] Finished CPU benchmarks
64-bit subsystem (recompiled):
2005-12-02 13:23:53 [---] Running CPU benchmarks
2005-12-02 13:24:51 [---] Benchmark results:
2005-12-02 13:24:51 [---] Number of CPUs: 1
2005-12-02 13:24:51 [---] 1664 double precision MIPS (Whetstone) per CPU
2005-12-02 13:24:51 [---] 4046 integer MIPS (Dhrystone) per CPU
2005-12-02 13:24:51 [---] Finished CPU benchmarks
Maybe I'm doing sth wrong, but...
having 64-bit binaries for linux would be nice.
The new Albert app would be a
)
The new Albert app would be a good point to start a 64 Bit test?!