This "pure" v4.38 result just finished and validated. It took about 61.5 hours to complete (compared to about 57 hours for v4.33 on the same host). Surprisingly, that was much better than the difference I reported for my other host.
This "pure" v4.38 result just finished and validated. It took about 61.5 hours to complete (compared to about 57 hours for v4.33 on the same host). Surprisingly, that was much better than the difference I reported for my other host.
Same for my Pentium M. They (and probably the Intel Core CPUs as well) seem to cope better with the code added in 4.38 to perform additional checks than the Pentium 4s.
This added code is probably not good for AMD? And now when I´ve a monster WU that should take ~50hr and give over 600cr cruncing with 4.33 that´s no good when next WU come´s with 4.38 and added ~10% extra crunchtime, luckely that the time to complete is a little bit longer today then in the beginning of the run.
My old Pentium III Coppermine running on Windows 98 has gotten validated results. The Work unit it was assigned for its first pure 4.38 result is not directly comparable to its last production result, but on a CPU seconds required per credit basis it slowed down, going from 628.1 to 689.5 or about 10%. I have less confidence in the accuracy of this result than in the approximately 14% Core 2 XP slowdown.
This added code is probably not good for AMD? And now when I´ve a monster WU that should take ~50hr and give over 600cr cruncing with 4.33 that´s no good when next WU come´s with 4.38 and added ~10% extra crunchtime, luckely that the time to complete is a little bit longer today then in the beginning of the run.
Note that this additional code applies only to the most recent beta version, the automatically distributed stock app doesn't have this. The focus of the beta test is to get as much test feedback and hopefully some debugging output from stalls/crashes in a short time, so it would be understandable if users running slower PCs or PCs that don't run for that many hours per day prefer not to use the beta app, IMHO.
This added code is probably not good for AMD? And now when I´ve a monster WU that should take ~50hr and give over 600cr cruncing with 4.33 that´s no good when next WU come´s with 4.38 and added ~10% extra crunchtime, luckely that the time to complete is a little bit longer today then in the beginning of the run.
Note that this additional code applies only to the most recent beta version, the automatically distributed stock app doesn't have this. The focus of the beta test is to get as much test feedback and hopefully some debugging output from stalls/crashes in a short time, so it would be understandable if users running slower PCs or PCs that don't run for that many hours per day prefer not to use the beta app, IMHO.
CU
H-BE
When I look at the page with the official app. it says 4.38 and that the same what I know they don´t use the same ver number on an official as a beta if it´s not the same. Or is I wrong here or can it be that it has been compiled with a newer version (VS2005) that makes it slower.
When I look at the page with the official app. it says 4.38 and that the same what I know they don´t use the same ver number on an official as a beta if it´s not the same.
Humm... that may be a change since yesterday.
Yesterday as part of my reversion from beta back to production testing, I did project resets on two machines after deleting their ap_info.xml files.
The application which was then newly downloaded had 433 as part of its file name. However looking at the Einstein project directory on my Core 2 Quad, I see that while the 433 is still there, and is the ap executing my four currently executing results, a new 438 ap was downloaded this morning, and is associated with my most recently downloaded result (about 9:30 a.m. this morning MDT). This also happened about the same time on my Core 2 Duo.
So I started this post to say you were wrong (based on my experience late yesterday), but with checking think you are right. I don't know whether that 4.38 is identical to the beta 4.38 or not.
I think the question as to whether 4.38 beta is slower on some observed platforms due to the intentional extra checking code added, or rather due to a different compiler is open.
This added code is probably not good for AMD? And now when I´ve a monster WU that should take ~50hr and give over 600cr cruncing with 4.33 that´s no good when next WU come´s with 4.38 and added ~10% extra crunchtime, luckely that the time to complete is a little bit longer today then in the beginning of the run.
Note that this additional code applies only to the most recent beta version, the automatically distributed stock app doesn't have this. The focus of the beta test is to get as much test feedback and hopefully some debugging output from stalls/crashes in a short time, so it would be understandable if users running slower PCs or PCs that don't run for that many hours per day prefer not to use the beta app, IMHO.
CU
H-BE
When I look at the page with the official app. it says 4.38 and that the same what I know they don´t use the same ver number on an official as a beta if it´s not the same. Or is I wrong here or can it be that it has been compiled with a newer version (VS2005) that makes it slower.
Ups, seems the 4.38 was installed today noon as the official app, so I stand corrected. OK, I guess that app will be a little slower now, but it will help to iron out the last few remaining stability issues, and this brings us closer to optimized apps in the future. . See it as an investment in future speed :-)
Quote:
I think the question as to whether 4.38 beta is slower on some observed platforms due to the intentional extra checking code added, or rather due to a different compiler is open.
The extra checks definitely take some time, and the new compiler (version) will not slow down the code, some speed improvement especially for SSE2 enabled machines seem likely. But the checks seem to be more significant.
Though the App is mostly a little slower than the previous one, we decided to push it out official to get some more feedback faster. I hope that it will be superseded by a faster one soon.
We're a bit under pressure now, for S5R3 we are relying on some issues to be fixed in the App.
We also pushed out the Linux App 4.37 to get rid of the "libz" errors.
This "pure" v4.38 result just finished and validated. It took about 61.5 hours to complete (compared to about 57 hours for v4.33 on the same host). Surprisingly, that was much better than the difference I reported for my other host.
Same for my Pentium M. They (and probably the Intel Core CPUs as well) seem to cope better with the code added in 4.38 to perform additional checks than the Pentium 4s.
CU
H-BE
Sorry for quoting somewhat older post.The difference is that Pentium 4 has bigger waste when most of jumps in code are called,since it has large number of steps for instructions(NetBurst arch) and when jump is done it has to dump more work on prefetched instructions than mother architectures.It was done for high frequencies(3.4GHz I think were the highest frequency stock CPUs)
http://einstein.phys.uwm.edu/
)
http://einsteinathome.org/task/86544231
This "pure" v4.38 result just finished and validated. It took about 61.5 hours to complete (compared to about 57 hours for v4.33 on the same host). Surprisingly, that was much better than the difference I reported for my other host.
RE: http://einstein.phys.uw
)
Same for my Pentium M. They (and probably the Intel Core CPUs as well) seem to cope better with the code added in 4.38 to perform additional checks than the Pentium 4s.
CU
H-BE
This added code is probably
)
This added code is probably not good for AMD? And now when I´ve a monster WU that should take ~50hr and give over 600cr cruncing with 4.33 that´s no good when next WU come´s with 4.38 and added ~10% extra crunchtime, luckely that the time to complete is a little bit longer today then in the beginning of the run.
My old Pentium III Coppermine
)
My old Pentium III Coppermine running on Windows 98 has gotten validated results. The Work unit it was assigned for its first pure 4.38 result is not directly comparable to its last production result, but on a CPU seconds required per credit basis it slowed down, going from 628.1 to 689.5 or about 10%. I have less confidence in the accuracy of this result than in the approximately 14% Core 2 XP slowdown.
RE: This added code is
)
Note that this additional code applies only to the most recent beta version, the automatically distributed stock app doesn't have this. The focus of the beta test is to get as much test feedback and hopefully some debugging output from stalls/crashes in a short time, so it would be understandable if users running slower PCs or PCs that don't run for that many hours per day prefer not to use the beta app, IMHO.
CU
H-BE
RE: RE: This added code
)
When I look at the page with the official app. it says 4.38 and that the same what I know they don´t use the same ver number on an official as a beta if it´s not the same. Or is I wrong here or can it be that it has been compiled with a newer version (VS2005) that makes it slower.
RE: When I look at the page
)
Humm... that may be a change since yesterday.
Yesterday as part of my reversion from beta back to production testing, I did project resets on two machines after deleting their ap_info.xml files.
The application which was then newly downloaded had 433 as part of its file name. However looking at the Einstein project directory on my Core 2 Quad, I see that while the 433 is still there, and is the ap executing my four currently executing results, a new 438 ap was downloaded this morning, and is associated with my most recently downloaded result (about 9:30 a.m. this morning MDT). This also happened about the same time on my Core 2 Duo.
So I started this post to say you were wrong (based on my experience late yesterday), but with checking think you are right. I don't know whether that 4.38 is identical to the beta 4.38 or not.
I think the question as to whether 4.38 beta is slower on some observed platforms due to the intentional extra checking code added, or rather due to a different compiler is open.
RE: RE: RE: This added
)
Ups, seems the 4.38 was installed today noon as the official app, so I stand corrected. OK, I guess that app will be a little slower now, but it will help to iron out the last few remaining stability issues, and this brings us closer to optimized apps in the future. . See it as an investment in future speed :-)
The extra checks definitely take some time, and the new compiler (version) will not slow down the code, some speed improvement especially for SSE2 enabled machines seem likely. But the checks seem to be more significant.
CU
H-BE
Though the App is mostly a
)
Though the App is mostly a little slower than the previous one, we decided to push it out official to get some more feedback faster. I hope that it will be superseded by a faster one soon.
We're a bit under pressure now, for S5R3 we are relying on some issues to be fixed in the App.
We also pushed out the Linux App 4.37 to get rid of the "libz" errors.
BM
BM
RE: RE: http://einstein.p
)
Sorry for quoting somewhat older post.The difference is that Pentium 4 has bigger waste when most of jumps in code are called,since it has large number of steps for instructions(NetBurst arch) and when jump is done it has to dump more work on prefetched instructions than mother architectures.It was done for high frequencies(3.4GHz I think were the highest frequency stock CPUs)
Hopefully it makes sense. :-)