Does this app fix the cross platform validation problems?
My take on that is "no", but perhaps the "instability" corrections really mean that?
I think it might have an impact, because some math routines have changed. The validattion problems are maybe founded in the different math-libs used under different operating systems. So taking these parts out of the app and code them in assembler might fix some problems.
I think it might have an impact, because some math routines have changed. The validattion problems are maybe founded in the different math-libs used under different operating systems. So taking these parts out of the app and code them in assembler might fix some problems.
Well, we'll see. I haven't been paired with anything other than XP systems in a while though...and even the couple of times I got paired with Linux, I never had a validation issue. Just lucky, I suppose... :shrug:
The hex-edited 4.17 app's result looks like it is going to finish either right at or just under 15 hours (54,000 seconds), so that is almost exactly 30% improvement for the hex edit way of addressing the AMD penalty. I'll see how the "approved" way compares... :-)
The Linux app doesn't use SSE (or SSE2) either, so this alone won't explain it. Maybe a build problem.
CU
BRM
The Linux was always faster than the Win app, even if the Win app uses SSE2. What I try to point out is that the new beta seems to be slower than the patched app and of cause faster than the offical app.
Maybe all that debugging code causes the slows down.
But I think first of all the validation problems should be solved, so let's hope. :-)
Maybe all that debugging code causes the slows down.
Not much - the additional code should mainly slow down the App when it's terminating anyway.
Quote:
But I think first of all the validation problems should be solved, so let's hope. :-)
My highest priority are still stability issues, i.e. client errors. The "validation problems" that may be fixed by this very App are only a few (i.e. those that occur in the sky position fields of the output - in case so cares). Reinhard Prix is currently looking into the differences in "singinficance field", which are probably the largest part.
One little thing: I guess the announcement here and on the beta page should read
...
"...speed up tasks on machines with AMD CPUs (and probably non-SSE2 Intel, too)."
...
Pentium IIIs, for example, should benefit, even tho SSE capable, because they lack SSE2 and are therefore executing the slow math-lib codepath with the old app.
Actually it would be interesting to see the performance on a PIII under windows. Anybody?
The Linux was always faster than the Win app, even if the Win app uses SSE2.
My 3700+ has now completed the last result I was working on with the edited app.
320.01 / 54246 * 3600 = 21.24 cr/hr (my host)
320.81 / 50786 * 3600 = 22.74 cr/hr (your host I was comparing against)
That is a roughly 7% delta. Beyond that, I don't know how much of a factor the difference in frequencies played in (409 for me, 410 for you), not to mention that my single-core has an inherent "handicap" (my system will take a bigger hit in performance when multi-tasking). In regards to that though, did my raw clock speed advantage (and also likely memory speed / latency advantage) outweigh the single-core disadvantage?
Quote:
Maybe all that debugging code causes the slows down.
What may slow it down some are the disk writes into stderr. If all that stuff is not really necessary, some performance improvement can be gained by not writing it all out...but otherwise, the debug info that they are talking about is the symbolic info in the PDB that is only called when the app crashes.
RE: RE: Does this app fix
)
I think it might have an impact, because some math routines have changed. The validattion problems are maybe founded in the different math-libs used under different operating systems. So taking these parts out of the app and code them in assembler might fix some problems.
cu,
Michael
I got the first very early
)
I got the first very early extrapolation:
[pre]
A64 X2 4400+@2.63GHz (win app 4.23) just one core:
sec % calc. total time credits cr/hr
6496 9,68 67107,44 317,99 17,06
7182 10,73 66933,83 317,99 17,10
This might end up with 17.5 - 18 cr/hr.
For comparison:
A64 X2 4400+@2.63GHz (win app 4.17 patched):
~ 20 cr/hr
A64 X2 4400+@2.63GHz (Linux app 4.21):
~ 22 cr/hr
[/pre]
It seems, the new app is slower than the patched app, probably because of not using SSE functions.
cu
Michael
RE: I think it might have
)
Well, we'll see. I haven't been paired with anything other than XP systems in a while though...and even the couple of times I got paired with Linux, I never had a validation issue. Just lucky, I suppose... :shrug:
The hex-edited 4.17 app's result looks like it is going to finish either right at or just under 15 hours (54,000 seconds), so that is almost exactly 30% improvement for the hex edit way of addressing the AMD penalty. I'll see how the "approved" way compares... :-)
RE: I got the first very
)
The Linux app doesn't use SSE (or SSE2) either, so this alone won't explain it.
CU
BRM
RE: The Linux app doesn't
)
The Linux was always faster than the Win app, even if the Win app uses SSE2. What I try to point out is that the new beta seems to be slower than the patched app and of cause faster than the offical app.
Maybe all that debugging code causes the slows down.
But I think first of all the validation problems should be solved, so let's hope. :-)
cu,
Michael
RE: Maybe all that
)
Not much - the additional code should mainly slow down the App when it's terminating anyway.
My highest priority are still stability issues, i.e. client errors. The "validation problems" that may be fixed by this very App are only a few (i.e. those that occur in the sky position fields of the output - in case so cares). Reinhard Prix is currently looking into the differences in "singinficance field", which are probably the largest part.
BM
BM
Hi! One little thing: I
)
Hi!
One little thing: I guess the announcement here and on the beta page should read
...
"...speed up tasks on machines with AMD CPUs (and probably non-SSE2 Intel, too)."
...
Pentium IIIs, for example, should benefit, even tho SSE capable, because they lack SSE2 and are therefore executing the slow math-lib codepath with the old app.
Actually it would be interesting to see the performance on a PIII under windows. Anybody?
CU
H-BE
BTW, to which URL would the
)
BTW, to which URL would the app "phone home" (for paranoid firewall config ;-) ) ?
Is the *.pdb already uploaded there?
CU
BRM
RE: The Linux was always
)
My 3700+ has now completed the last result I was working on with the edited app.
320.01 / 54246 * 3600 = 21.24 cr/hr (my host)
320.81 / 50786 * 3600 = 22.74 cr/hr (your host I was comparing against)
That is a roughly 7% delta. Beyond that, I don't know how much of a factor the difference in frequencies played in (409 for me, 410 for you), not to mention that my single-core has an inherent "handicap" (my system will take a bigger hit in performance when multi-tasking). In regards to that though, did my raw clock speed advantage (and also likely memory speed / latency advantage) outweigh the single-core disadvantage?
What may slow it down some are the disk writes into stderr. If all that stuff is not really necessary, some performance improvement can be gained by not writing it all out...but otherwise, the debug info that they are talking about is the symbolic info in the PDB that is only called when the app crashes.
RE: BTW, to which URL would
)
It will contact the "Symbol Store" at http://einstein.phys.uwm.edu/symstore/
BM
BM