This result was about 95% done Windows beta 4.26 when I restarted it on beta 4.32.
It finished and has validated. That is a modest confidence-builder that mid-stream conversion is likely to work 4.26 to 4.32.
That host was a WinXP Conroe-class Quad (Q6600), also converted without apparent initial complaint were a WinXP Conroe (E6600), a WinXP Banias, and a Win98SE Coppermine (Yes, CPU-Z lists it as handling SSE).
Nice timing, Bernd! My host 1001562 has just been allocated its first 800+ dataset, so I was already starting to flush out sub-800 tasks and run down other project caches. I'm installing 4.32 now, so I'm aiming for a clean timing run on 909.15Hz, from sequence number 502 down as far as the server will let me. Q6600 at stock 2.4GHz, all four cores dedicated to Einstein for the duration of the run: none of the times tasks have started yet, so they will all be exclusively done with 4.32.
The App will probably have some CPU vendor detection linked into it (as the 4.26 has), but my guess is that the linear sin/cos code that we're using now isn't affected by this noticeably, so there should be no "penalty" for AMD users. Please try to prove me wrong!
I have finished my first result with pure 4.32 (and valid) http://einsteinathome.org/task/92190525
This application is really fast. My fastest time before was 16.800s and now it is 11.800. The CPU is a E8400 @ 4.2 Ghz.
I hope 4.32 prove to be stable.
Well, I don't have anything definitive to post yet, but I can tell you that looking at my current result, 4.26 was giving mostly 2 sky positions between checkpoints (the "c" in the output file). There were a few lines that had 3, but mostly 2. With 4.32, I'm now seeing mostly 3 between checkpoints, with only a few instances of 2 positions between checkpoints.
From that, I'm inclined to believe that there is at least 25-30% improvement in performance... This is without trying to address any AMD-specific penalties...
I should point out that I had a lot of help from Bikeman on this App. I wouldn't say that it were impossible without him, but it had taken me much, much longer.
I have finished my first result with pure 4.32 (and valid) http://einsteinathome.org/task/92190525
This application is really fast. My fastest time before was 16.800s and now it is 11.800. The CPU is a E8400 @ 4.2 Ghz.
I hope 4.32 prove to be stable.
hotze
Then i say its faster than 4.27 for Linux. I never got times below 12k with E8400 at 4.2GHz.
I should point out that I had a lot of help from Bikeman on this App. I wouldn't say that it were impossible without him, but it had taken me much, much longer.
BM
Don't give him too much credit, or you'll have to buy him new boots; he'll be too big for them. ;-)
My first "pure" 4.32 result on my Q6600 has validated with 24201 CPU seconds. The expected value for its sequence number and frequency on my previous modeling was 30830 seconds. So it took 78.5% as long as expected, or the host at initial estimate will be 1.27 times as productive as before.
This host is a quad, and has considerably more noise in the completion time vs. phase angle that does my duo, and I suspect that noise is even worse near the peak time sequence numbers. This was very close to peak time (estimated phase .992) so any error in the period estimate is also amplified. There is also no good reason to assume the runtime variance for this ap will be the same on this host as for 4.26. As the trough (middling phase angle) results dominate productivity, a different variance could drive this to be considerable better or worse.
[edit] After I wrote that my E6600 host finished its first pure 4.32 result in 22448 CPU seconds. Conveniently this was a sequence number 0 result so the comparison to expectation of 29453 is really easy. This one gives a peak of sequence estimate improvement of 76% of previous CPU time, or 1.31 times more productive. It does not help on the variance question.[/edit]
A very nice speedup--let's hope it turns out not to have any nasty habits.
This result was about 95%
)
This result was about 95% done Windows beta 4.26 when I restarted it on beta 4.32.
It finished and has validated. That is a modest confidence-builder that mid-stream conversion is likely to work 4.26 to 4.32.
That host was a WinXP Conroe-class Quad (Q6600), also converted without apparent initial complaint were a WinXP Conroe (E6600), a WinXP Banias, and a Win98SE Coppermine (Yes, CPU-Z lists it as handling SSE).
Nice timing, Bernd! My host
)
Nice timing, Bernd! My host 1001562 has just been allocated its first 800+ dataset, so I was already starting to flush out sub-800 tasks and run down other project caches. I'm installing 4.32 now, so I'm aiming for a clean timing run on 909.15Hz, from sequence number 502 down as far as the server will let me. Q6600 at stock 2.4GHz, all four cores dedicated to Einstein for the duration of the run: none of the times tasks have started yet, so they will all be exclusively done with 4.32.
RE: The App will probably
)
Oh, trust me, I'll try... ;-)
I have finished my first
)
I have finished my first result with pure 4.32 (and valid)
http://einsteinathome.org/task/92190525
This application is really fast. My fastest time before was 16.800s and now it is 11.800. The CPU is a E8400 @ 4.2 Ghz.
I hope 4.32 prove to be stable.
hotze
Well, I don't have anything
)
Well, I don't have anything definitive to post yet, but I can tell you that looking at my current result, 4.26 was giving mostly 2 sky positions between checkpoints (the "c" in the output file). There were a few lines that had 3, but mostly 2. With 4.32, I'm now seeing mostly 3 between checkpoints, with only a few instances of 2 positions between checkpoints.
From that, I'm inclined to believe that there is at least 25-30% improvement in performance... This is without trying to address any AMD-specific penalties...
Just switched over with no
)
Just switched over with no problems at all on my Q6600. I've got 4 jobs that transitioned over smoothly.
Let's see how fast this baby can crunch. =D
I should point out that I had
)
I should point out that I had a lot of help from Bikeman on this App. I wouldn't say that it were impossible without him, but it had taken me much, much longer.
BM
BM
RE: I have finished my
)
Then i say its faster than 4.27 for Linux. I never got times below 12k with E8400 at 4.2GHz.
Team Philippines
RE: I should point out that
)
Don't give him too much credit, or you'll have to buy him new boots; he'll be too big for them. ;-)
My first "pure" 4.32 result
)
My first "pure" 4.32 result on my Q6600 has validated with 24201 CPU seconds. The expected value for its sequence number and frequency on my previous modeling was 30830 seconds. So it took 78.5% as long as expected, or the host at initial estimate will be 1.27 times as productive as before.
This host is a quad, and has considerably more noise in the completion time vs. phase angle that does my duo, and I suspect that noise is even worse near the peak time sequence numbers. This was very close to peak time (estimated phase .992) so any error in the period estimate is also amplified. There is also no good reason to assume the runtime variance for this ap will be the same on this host as for 4.26. As the trough (middling phase angle) results dominate productivity, a different variance could drive this to be considerable better or worse.
[edit] After I wrote that my E6600 host finished its first pure 4.32 result in 22448 CPU seconds. Conveniently this was a sequence number 0 result so the comparison to expectation of 29453 is really easy. This one gives a peak of sequence estimate improvement of 76% of previous CPU time, or 1.31 times more productive. It does not help on the variance question.[/edit]
A very nice speedup--let's hope it turns out not to have any nasty habits.