It seems me that one aspect of the 64bit architecture has been overlooked in the post on this thread. Specifically the efficiency of virtual to physical address translation.
A while ago i did switch to the newer XP 64-bit on my AMD64. I saw an increase in my crunching time, because windows had to emulate a 32-bit os to run it. So i had to switch back to 32-bit. If if we just had a native x86_64 client it wouldn't have to emulate it, so then i could upgrade back. Since i know there must be others right now that are running a 64-bit windows their times are being increased, and if you just released a native x86_64 app it would go back to normal or maybe even reduce the amount of time it takes to crunch it. Even if it was just a 5% decrease it would decrease it by about 640 seconds/per WU.
I would question how many computer platforms (OS and hardware) are ready for 64 bit? Going through the stats, pulling 'Microsoft Windows 2003' and LIKE 'Professional Edition*', I come up with 868 computers. Going forward, there has to be some easy way to tell which OS/processor combo is 64 bit ready. Looking at the Linux 'os_version' information just for 'p_model' like '*Opteron' is a real mess. The only current platform that is almost 100% 64 bit is SPARC/Solaris but there are only about 95 machines. The hardware and the OS has been 64 bit for quite a while. There are a few older 32bit machines working though.
i hope someday a IA64 Bit client will be produced for linux or windows.
but i think nobody has the time and the knowledge to do because IA64 is much more different of the amd-64 fake.
if a 64bit client is available it will be great i can run Einstein on my Intel Itanium Machines like the old Seti@home (5 min for a workunit).
A 64 bit App would be wonderful. But I don't think some folks understand that x86 64 bit, and IA 64 bit are 2 completely different cpus. The x86 64 bit would run fine recompiled/wrote for 64 bit useing the same x86 coding. The IA64 bit procs are completly different, they do not use the x86 coding, it was thrown out. The best they can do is a emulation of 32 bit code to run a 32 bit program.Which it does very badly, compared to what they can do in a native IA64 App.
So a client for IA-64 would not run on a x-64 unit, as will not a client for x-64 run on a IA-64 system. They would have to be 2 completely different applications.
I'll add my name to the wishlist requesting an x86-64 app. Processors and OS's are already around, and eventually when M$ Vista hits, there'll be alot more boxes with 64bit capability. The processors in these boxes are newer and more powerful as well, so if there is even a modest performance gain, it will add up.
From my point of view, I put 64bit linux on my box, and though possibe to put 32bit apps on it, I choose to only install 32bit apps when absolutely neccesary. I accept being bleeding edge and that's fine. I just hope that for BOINC/projects having Linux, BSD, SPARC versions of their software, you would be progressive enough to start looking at x86-64. You can count me in for being a beta tester.
From my experience with Setiathome, which is the only open source science app in Boinc world, 64-bit version of it was many times slower than 32-bit version of it.
I don't see anything wrong with running 32-bit code on 64-bit host. One of the greatest selling points of the amd64 chips was running i386 code without slowdown, right?
It's not like anyone is forcing you to run 32-bit boinc client. But the science apps are better off with 32-bit math.
From my experience with Setiathome, which is the only open source science app in Boinc world, 64-bit version of it was many times slower than 32-bit version of it.
It depends on the CPU. With SETI 4.x the 64 bit binaries on IA64 was about 20 % faster with 64 Bit, the PARISC about 15 % faster.
The new SETI Enhanced 5.x was about 5 to 10 % faster in 64 Bit on the IA64 and PARISC, if you use the fftw libs.
SIMAP is about 5 % faster with 64 bit on PARISC. But the SPARC 64 bit binary is about 10 % slower compared with the 32 bit one...
To quote David Stanford:
[pre]If you were to devise a program that would utilize my 64 bit pathway
my processing speed (And many others') would almost double.[/pre]
This is a common belief, but it's wrong... A "64-bit" processor has integers and addresses that can be 64-bits, but the size of floating point numbers is the same - a double precision Float is already 64 bits!
Think of a 64-bit processor as giving you the ability to work with larger numbers, but not any faster than a 32-bit processor. About the only programs that really benefit from a 64-bit processor are very large databases (where 32-bit addresses are not long enough to fit all the index data) and cryptographic operations (which use arithmetic on very large integers).
In the particular case of the AMD64 instructions versus the current IA-32 ones, there can be a benefit in general performance because the 64-bit programs have access to more registers to hold temporary results, but it would not be anything like a 2x increase, and for many programs there would be no noticable difference at all.
In the general case, if you take a typical program and do a straight 32-64 bit translation on the same architecture, the new one will actually be slower because the added size of the longer integers and addresses eat up more memory bandwidth and cache space.
What could yield a big benefit is if it were possible to recode the program to make use of SSE2 instructions. They may already be using them (I don't know), and many codes can't easily be vectorized. This is about the only way you might see a 2x performance increase. (Unless you switch from a poor compiler to a very clever one, but I don't want to start that discussion right now...)
- Warren Marts
RE: using the SSE2 instructions: this would make the app using them un-available to people that are still using processors (like the Sempron 2400+, which I was using until this March) that don't support that instruction set. Same comment for the SSE3 instruction set... if someone would come out with an optimized version of the standard E@H application, (like the "Chicken of Agnor"'s optimised SETI apps) you could use that...
A while ago i did switch to the newer XP 64-bit on my AMD64. I saw an increase in my crunching time, because windows had to emulate a 32-bit os to run it. So i had to switch back to 32-bit. If if we just had a native x86_64 client it wouldn't have to emulate it, so then i could upgrade back. Since i know there must be others right now that are running a 64-bit windows their times are being increased, and if you just released a native x86_64 app it would go back to normal or maybe even reduce the amount of time it takes to crunch it. Even if it was just a 5% decrease it would decrease it by about 640 seconds/per WU.
you may have seen an increase of time to crunch, but the reason is not that XP pro x64 is emulating x32 — the reason is that XP Pro x64 is shifting back and forth between 32 bit and 64 bit operation. (which has a bit of overhead involved) Anything written (or at least re-compiled) for 64 bit operation is run in 64 bit mode; anything that still has the 32 bit tags on the .exe is run in 32 bit mode, which the AMD's (I'm running one as I type) are perfectly capable of... (I dual boot XP Home Ed. and XP Pro x64... and have read some of the theory and methods of operation behind the x64 edition...)
It seems me that one aspect
)
It seems me that one aspect of the 64bit architecture has been overlooked in the post on this thread. Specifically the efficiency of virtual to physical address translation.
A while ago i did switch to
)
A while ago i did switch to the newer XP 64-bit on my AMD64. I saw an increase in my crunching time, because windows had to emulate a 32-bit os to run it. So i had to switch back to 32-bit. If if we just had a native x86_64 client it wouldn't have to emulate it, so then i could upgrade back. Since i know there must be others right now that are running a 64-bit windows their times are being increased, and if you just released a native x86_64 app it would go back to normal or maybe even reduce the amount of time it takes to crunch it. Even if it was just a 5% decrease it would decrease it by about 640 seconds/per WU.
I would question how many
)
I would question how many computer platforms (OS and hardware) are ready for 64 bit? Going through the stats, pulling 'Microsoft Windows 2003' and LIKE 'Professional Edition*', I come up with 868 computers. Going forward, there has to be some easy way to tell which OS/processor combo is 64 bit ready. Looking at the Linux 'os_version' information just for 'p_model' like '*Opteron' is a real mess. The only current platform that is almost 100% 64 bit is SPARC/Solaris but there are only about 95 machines. The hardware and the OS has been 64 bit for quite a while. There are a few older 32bit machines working though.
Hello Freaks :-) i hope
)
Hello Freaks :-)
i hope someday a IA64 Bit client will be produced for linux or windows.
but i think nobody has the time and the knowledge to do because IA64 is much more different of the amd-64 fake.
if a 64bit client is available it will be great i can run Einstein on my Intel Itanium Machines like the old Seti@home (5 min for a workunit).
Thx
A 64 bit App would be
)
A 64 bit App would be wonderful. But I don't think some folks understand that x86 64 bit, and IA 64 bit are 2 completely different cpus. The x86 64 bit would run fine recompiled/wrote for 64 bit useing the same x86 coding. The IA64 bit procs are completly different, they do not use the x86 coding, it was thrown out. The best they can do is a emulation of 32 bit code to run a 32 bit program.Which it does very badly, compared to what they can do in a native IA64 App.
So a client for IA-64 would not run on a x-64 unit, as will not a client for x-64 run on a IA-64 system. They would have to be 2 completely different applications.
Come Join us at Hawaiian Beach Bums
I'll add my name to the
)
I'll add my name to the wishlist requesting an x86-64 app. Processors and OS's are already around, and eventually when M$ Vista hits, there'll be alot more boxes with 64bit capability. The processors in these boxes are newer and more powerful as well, so if there is even a modest performance gain, it will add up.
From my point of view, I put 64bit linux on my box, and though possibe to put 32bit apps on it, I choose to only install 32bit apps when absolutely neccesary. I accept being bleeding edge and that's fine. I just hope that for BOINC/projects having Linux, BSD, SPARC versions of their software, you would be progressive enough to start looking at x86-64. You can count me in for being a beta tester.
Thanks
Matt
From my experience with
)
From my experience with Setiathome, which is the only open source science app in Boinc world, 64-bit version of it was many times slower than 32-bit version of it.
I don't see anything wrong with running 32-bit code on 64-bit host. One of the greatest selling points of the amd64 chips was running i386 code without slowdown, right?
It's not like anyone is forcing you to run 32-bit boinc client. But the science apps are better off with 32-bit math.
RE: From my experience with
)
It depends on the CPU. With SETI 4.x the 64 bit binaries on IA64 was about 20 % faster with 64 Bit, the PARISC about 15 % faster.
The new SETI Enhanced 5.x was about 5 to 10 % faster in 64 Bit on the IA64 and PARISC, if you use the fftw libs.
SIMAP is about 5 % faster with 64 bit on PARISC. But the SPARC 64 bit binary is about 10 % slower compared with the 32 bit one...
RE: To quote David
)
RE: using the SSE2 instructions: this would make the app using them un-available to people that are still using processors (like the Sempron 2400+, which I was using until this March) that don't support that instruction set. Same comment for the SSE3 instruction set... if someone would come out with an optimized version of the standard E@H application, (like the "Chicken of Agnor"'s optimised SETI apps) you could use that...
RE: A while ago i did
)
you may have seen an increase of time to crunch, but the reason is not that XP pro x64 is emulating x32 — the reason is that XP Pro x64 is shifting back and forth between 32 bit and 64 bit operation. (which has a bit of overhead involved) Anything written (or at least re-compiled) for 64 bit operation is run in 64 bit mode; anything that still has the 32 bit tags on the .exe is run in 32 bit mode, which the AMD's (I'm running one as I type) are perfectly capable of... (I dual boot XP Home Ed. and XP Pro x64... and have read some of the theory and methods of operation behind the x64 edition...)