There are 64-bit clients for HP-UX, IRIX, Tru64, and Solaris. If you're referring to a Linux AMD64 or Windows AMD64 client, I'm wondering as well. Got an Opteron 144 here that could be used for testing...
Greg
Will we see a 64-bit client in the future??
There are 64-bit clients for HP-UX, IRIX, Tru64, and Solaris. If you're referring to a Linux AMD64 or Windows AMD64 client, I'm wondering as well. Got an Opteron 144 here that could be used for testing...
Greg
If you have Linux 64 Bit installed, or WinXP64 Beta, you will find the Client runs
5-10% faster as it is
I am not a Stats Ho, it is just more satisfying to see that my numbers are better than yours.
only 5-10% ???
That's good, because it means that the O.S. overhead is small.
HOME: A physical construct for keeping rain off your computers.
5-10 % is a worst case scenario, we really need users to benchmark the Client on 32 Bit then 64 Bit and post results to get good data. The reality is that on Linux and Win64, going 64 Bit is showing up to 15% speed improvement just due to the fact the FP & Integer crunching is more efficient on non optimized code. So even if we do not see a AMD64 Client, as the 64 Bit OS's mature, there will be reasonable gains.
Update: Here are some results for a Athlon64 3200+ @ 2.1 Ghz
32 Bit XP
Maketrj 5.656 0.141
Foldtraj 30.313 4.828
Win64
Maketrj 5.547 0.328
Foldtraj 26.844 8.094
Last edited by Grumpy; 02-13-2004 at 01:16 PM.
I am not a Stats Ho, it is just more satisfying to see that my numbers are better than yours.
Running a 32-bit client on a 64-bit OS doesn't make much of a difference. In fact I'm surprised that it made that much...10%! I've got a similar benchmark in the benchmarks thread, copied below:
Opteron 144 running at 1.8GHz
1GB PC3200 Reg. ECC Dual Channel RAM
Windows Server 2003 AMD64
Usr time Sys time
-------- --------
Maketrj 6.328 0.219
Foldtraj 30.141 6.844
What could REALLY make a difference...depending on the math...is a 64-bit client. That's what we're really hoping for!
Greg
Exactly -- depending on the math.Originally posted by frmky
What could REALLY make a difference...depending on the math...
DF doesn't do a lot of math. Most of its processing time is spent chasing pointers.
Whether your processor's registers are 32 bits wide or 64 bits wide, a pointer is the same size (at least, on sane architectures -- long gone are the days of x86 real mode, where pointers were 20 bits but the processor was 16 or 24 or 32, and it used some freaky segmentation scheme to get them to map...). So it won't get a huge boost.
Now, if the new architecture's math is a bit faster, it'll help -- but only up to the point where the DF client actually does that math.
It was called Amdahl's Law in my Computer Architecture class: you should try to optimize the places where whatever you're doing is spending the most time. If you double the speed that math runs at, but the client is only doing math 10% of the time, then you'll only get a 5% increase in the client's overall speed. (These numbers are made up; I don't know what percentage of the time the client is doing math vs. chasing pointers vs. waiting for the network to respond () when trying to upload vs. anything else.)
"If you fail to adjust your notion of fairness to the reality of the Universe, you will probably not be happy."
-- Originally posted by Paratima
Howard mentioned how much time was spent dealing with pointers.. and how little with math in the threads requesting altivec optimization, SSE optimization, and 3dnow optimization. (It's been mentioned.. but good luck finding the quote..
We won't get an AMD 64 bit client until Bryan has an AMD 64 bit machine in house to test it on. And preferably a few - so they can have different 64 bit OSes on 'em. And it might help to have some of the 64 bit coders from AMD stop by to help demonstrate how to optimize the code for the 64 bit AMD cpu.
I got in touch with the AMD 64 bit PR department - but they kept sending me voice mail of a fellow that was taking vacations every time I called. I was going to see if they'd donate hardware and help get the code optimized so it runs faster in both 32 bit mode and 64 bit mode than on.. the Itanic.. Alas, I got busy at work, and lost track of calling them back. I'll gladly pass the torch off to someone else that might have better luck finding out when that fellow ISN'T on vacation. *grin*
www.thegenomecollective.com
Borging.. it's not just an addiction. It's...
Funny that the F@H clients seem to almost double their speed when SSE or Altivec are enabled. They are doing protein folding as well, I guess the techniques are different.Originally posted by tpdooley
Howard mentioned how much time was spent dealing with pointers.. and how little with math in the threads requesting altivec optimization, SSE optimization, and 3dnow optimization. (It's been mentioned.. but good luck finding the quote..
...
Obviously they are...
Isn't F@H trying to figure out how they fold, instead of just what they look like? I can see that taking an entirely different set of algorithms, definitely.
"If you fail to adjust your notion of fairness to the reality of the Universe, you will probably not be happy."
-- Originally posted by Paratima