Interesting. Twice the rate with AMD chips running 3D Now! and a 30% hit on the 64 XPs. That's enough to make a person want to switch.:)
Gary
LOL....
Maybe, except for like hotrodding, MHz are hard to beat when your looking to get any finish line first! Gas milage don't count for much then. ;-)
Also, since there isn't any optimization to speak of in the app at the moment, MMX, SSEx, and 3DNow! aren't coming into play. We're looking at sheer FPU performance right now. So the conclusion I'm drawing is the performance of the SIMD engines in the CPUs has taken a quantum leap compared to the FPU with the later generations.
The active host graph is up again, all because of SETI problems with Master Science Database. Several krunchers (including me) are back to E@H for the time being...
Interesting. Twice the rate with AMD chips running 3D Now! and a 30% hit on the 64 XPs. That's enough to make a person want to switch.:)
YOu'll see the same thing on old Pentium 2's that don't have SSE. All modern chips (p3+, athlonXP+) have SSE which is significantly faster for floating point math than the x87 FPU. The x86 s5r1 app had x87 and SSE versions, the s5r2 app currently only has an x87 build which is significantly narrowing the spread between new and old chips.
Right, and here I was thinking that a goal of new code was to *optimize* for newer performance capabilities rather than 'de-optimize' -- after all, the poor folks running Vista *must* have higher performance so perhaps the Einstein folks are really producing code with a view toward punishing newer CPU's....
Quote:
YOu'll see the same thing on old Pentium 2's that don't have SSE. All modern chips (p3+, athlonXP+) have SSE which is significantly faster for floating point math than the x87 FPU. The x86 s5r1 app had x87 and SSE versions, the s5r2 app currently only has an x87 build which is significantly narrowing the spread between new and old chips.
Right, and here I was thinking that a goal of new code was to *optimize* for newer performance capabilities rather than 'de-optimize' -- after all, the poor folks running Vista *must* have higher performance so perhaps the Einstein folks are really producing code with a view toward punishing newer CPU's....
There's currently no SSE code for the same reason that there's no bsd app, no solaris app, no assembly based hot loop etc. Tracking down the handful of remaining algorithmic bugs is a higher priority than optimizing the code and porting to additional platforms.
Well the the K6/300 made it with about 11 hours to spare, and this was with a particularly ugly neighborhood wide 4-5 hour power outage about half way through the run.
204.45 CS 1,064,179.76 seconds.
So it looks to me that any PII Deschutes or higher Intel should be able to make it within the deadline. PI-MMX might be able to make it at 233 MHz given the generally stronger FPU's they had compared to AMD back then, but giving up almost a third in clockspeed makes me think it would really tough and would have absolutely zero time margin. Obviously this AMD old timer is about as far as you can go back in time with them. ;-)
My second S5R2 run on a 400 MHz PII Deschutes running Linux confirms the first:
204 credits, 293k s. App was 414, my new run seems to be 418. Wait and see.
Tullio
Your Deschutes can probably even handle the 'big boy' WU's in time. My other K6/300 is chewing on one now, but it's not looking too good time wise at this point.
Sounds like my Coppermine should be okay, though it's not running 24/7.
My host Dell1 is a Coppermine with a frequency near 1 GHz (930 MHz, I think)
It has processed three 300-cobblestone S5R2 results in 69 CPU-hours each and is getting credit. There are larger results out there (largest I know about are a bit over 400 cobblestone), as its Einstein allocation is very high, I expect it to finish OK. By 1 GHz, a Coppermine is seriously short of memory bandwidth, so the slower frequency ones do a bit better than simple scaling would suggest.
RE: Interesting. Twice the
)
LOL....
Maybe, except for like hotrodding, MHz are hard to beat when your looking to get any finish line first! Gas milage don't count for much then. ;-)
Also, since there isn't any optimization to speak of in the app at the moment, MMX, SSEx, and 3DNow! aren't coming into play. We're looking at sheer FPU performance right now. So the conclusion I'm drawing is the performance of the SIMD engines in the CPUs has taken a quantum leap compared to the FPU with the later generations.
Alinator
The active host graph is up
)
The active host graph is up again, all because of SETI problems with Master Science Database. Several krunchers (including me) are back to E@H for the time being...
RE: Interesting. Twice
)
YOu'll see the same thing on old Pentium 2's that don't have SSE. All modern chips (p3+, athlonXP+) have SSE which is significantly faster for floating point math than the x87 FPU. The x86 s5r1 app had x87 and SSE versions, the s5r2 app currently only has an x87 build which is significantly narrowing the spread between new and old chips.
Right, and here I was
)
Right, and here I was thinking that a goal of new code was to *optimize* for newer performance capabilities rather than 'de-optimize' -- after all, the poor folks running Vista *must* have higher performance so perhaps the Einstein folks are really producing code with a view toward punishing newer CPU's....
RE: Right, and here I was
)
There's currently no SSE code for the same reason that there's no bsd app, no solaris app, no assembly based hot loop etc. Tracking down the handful of remaining algorithmic bugs is a higher priority than optimizing the code and porting to additional platforms.
Well the the K6/300 made it
)
Well the the K6/300 made it with about 11 hours to spare, and this was with a particularly ugly neighborhood wide 4-5 hour power outage about half way through the run.
204.45 CS 1,064,179.76 seconds.
So it looks to me that any PII Deschutes or higher Intel should be able to make it within the deadline. PI-MMX might be able to make it at 233 MHz given the generally stronger FPU's they had compared to AMD back then, but giving up almost a third in clockspeed makes me think it would really tough and would have absolutely zero time margin. Obviously this AMD old timer is about as far as you can go back in time with them. ;-)
Alinator
My second S5R2 run on a 400
)
My second S5R2 run on a 400 MHz PII Deschutes running Linux confirms the first:
204 credits, 293k s. App was 414, my new run seems to be 418. Wait and see.
Tullio
Your Deschutes can probably
)
Your Deschutes can probably even handle the 'big boy' WU's in time. My other K6/300 is chewing on one now, but it's not looking too good time wise at this point.
Alinator
Sounds like my Coppermine
)
Sounds like my Coppermine should be okay, though it's not running 24/7.
RE: Sounds like my
)
My host Dell1 is a Coppermine with a frequency near 1 GHz (930 MHz, I think)
It has processed three 300-cobblestone S5R2 results in 69 CPU-hours each and is getting credit. There are larger results out there (largest I know about are a bit over 400 cobblestone), as its Einstein allocation is very high, I expect it to finish OK. By 1 GHz, a Coppermine is seriously short of memory bandwidth, so the slower frequency ones do a bit better than simple scaling would suggest.
Good luck.