Okay if no one is wondering it must be normal, that under Linux a Pentium M with 20% less Core-Freq is 11% faster than a Pentium M under Windows.
Next WU on the 1.6 is due in 10 hours, would be ~51300 s. On the 2.0 under Windows next one would be ~57500 s.
So don't take Windows...
There are several things to take into account here, one is that the workunits vary in runtime considerably (sometimes up to +/- 20 %). The other thing is that the Linux app can make use of SSE2, which the Windows app will not. The third thing is that the Linux app has some algorithmic optimization that did not yet make it into the Windows built. So it's not really the fault of the operating system per se (just to make sure there are no misunderstandings).
optimization that did not yet make it into the Windows built.
Bikeman
I hope some kind of optimization makes it into the Windows build because my R3 tasks on P4/HT took 17-18 hours whilst the R4 tasks are taking nearly 30 hours (not to mention reduced credit; ...err, oh, did I mention that?)!
Well, whether we like it or not, the credit drop is intentional to bring E@H back in line with other projects , namely SETI@Home, in terms of credit per CPU hour. So any further optimizations would, in the long run, result in further credit cuts. But I do understand that in general, shorter runtime per WU is favored.
Further optimizations are of course beneficial for the science "throughput" whatever the credit scheme is, so it's obvious that the official developers and the volunteers will continue to improve the apps. At the end of S5R4, Linux and Windows were almost equally contributing to E@H, so both platforms are equally important.
Further optimizations are of course beneficial for the science "throughput" whatever the credit scheme is, so it's obvious that the official developers and the volunteers will continue to improve the apps. At the end of S5R4, Linux and Windows were almost equally contributing to E@H, so both platforms are equally important.
I think you meant S5R3. Additionally, I don't know what your definition of "almost" is, but the reference unit shows around 20% advantage for Linux due to the code differences (not SSE vs. SSE2, but the other optimizations)...
I know this is being worked on...but others may not know. As such, you may want to refine your "Common Answer" on the subject... ;-)
Further optimizations are of course beneficial for the science "throughput" whatever the credit scheme is, so it's obvious that the official developers and the volunteers will continue to improve the apps. At the end of S5R4, Linux and Windows were almost equally contributing to E@H, so both platforms are equally important.
I think you meant S5R3. Additionally, I don't know what your definition of "almost" is, but the reference unit shows around 20% advantage for Linux due to the code differences (not SSE vs. SSE2, but the other optimizations)...
I know this is being worked on...but others may not know. As such, you may want to refine your "Common Answer" on the subject... ;-)
Hi!
Yes, I meant S5R3, sorry for the confusion. When I said that Windows and Linux were almost equally contributing to E@H, I meant that the number of results returned by either platform was about equal. While the Windows boxes outnumber the Linux boxes, there seems to be a great number of very active Linux boxes in science institutions/clusters.
Further optimizations are of course beneficial for the science "throughput" whatever the credit scheme is, so it's obvious that the official developers and the volunteers will continue to improve the apps. At the end of S5R4, Linux and Windows were almost equally contributing to E@H, so both platforms are equally important.
I think you meant S5R3. Additionally, I don't know what your definition of "almost" is, but the reference unit shows around 20% advantage for Linux due to the code differences (not SSE vs. SSE2, but the other optimizations)...
I know this is being worked on...but others may not know. As such, you may want to refine your "Common Answer" on the subject... ;-)
Hi!
Yes, I meant S5R3, sorry for the confusion. When I said that Windows and Linux were almost equally contributing to E@H, I meant that the number of results returned by either platform was about equal. While the Windows boxes outnumber the Linux boxes, there seems to be a great number of very active Linux boxes in science institutions/clusters.
Bikeman
Well, there's that...and the performance advantage ;-)
(Not directed at you, more through you...or, like was said in Spaceballs, "more to the side")
No you haven't got the point,
)
No you haven't got the point, i was wondering about the runtime...
RE: No you haven't got the
)
Well indulge us then. What is it about the runtime that you are wondering about? :-)
Currently on the table ( my parsing ):
- Is Windows that lame?
- the CPU of that monster size as the Claimed Credit hints at?
- the granted credit is somewhat low and seems to be non-adjusted?
Cheers, Mike. :-)
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Okay if no one is wondering
)
Okay if no one is wondering it must be normal, that under Linux a Pentium M with 20% less Core-Freq is 11% faster than a Pentium M under Windows.
Next WU on the 1.6 is due in 10 hours, would be ~51300 s. On the 2.0 under Windows next one would be ~57500 s.
So don't take Windows...
Hi! There are several
)
Hi!
There are several things to take into account here, one is that the workunits vary in runtime considerably (sometimes up to +/- 20 %). The other thing is that the Linux app can make use of SSE2, which the Windows app will not. The third thing is that the Linux app has some algorithmic optimization that did not yet make it into the Windows built. So it's not really the fault of the operating system per se (just to make sure there are no misunderstandings).
Bikeman
RE: optimization that did
)
I hope some kind of optimization makes it into the Windows build because my R3 tasks on P4/HT took 17-18 hours whilst the R4 tasks are taking nearly 30 hours (not to mention reduced credit; ...err, oh, did I mention that?)!
Well, whether we like it or
)
Well, whether we like it or not, the credit drop is intentional to bring E@H back in line with other projects , namely SETI@Home, in terms of credit per CPU hour. So any further optimizations would, in the long run, result in further credit cuts. But I do understand that in general, shorter runtime per WU is favored.
Further optimizations are of course beneficial for the science "throughput" whatever the credit scheme is, so it's obvious that the official developers and the volunteers will continue to improve the apps. At the end of S5R4, Linux and Windows were almost equally contributing to E@H, so both platforms are equally important.
Bikeman
RE: Further optimizations
)
I think you meant S5R3. Additionally, I don't know what your definition of "almost" is, but the reference unit shows around 20% advantage for Linux due to the code differences (not SSE vs. SSE2, but the other optimizations)...
I know this is being worked on...but others may not know. As such, you may want to refine your "Common Answer" on the subject... ;-)
RE: RE: Further
)
Hi!
Yes, I meant S5R3, sorry for the confusion. When I said that Windows and Linux were almost equally contributing to E@H, I meant that the number of results returned by either platform was about equal. While the Windows boxes outnumber the Linux boxes, there seems to be a great number of very active Linux boxes in science institutions/clusters.
Bikeman
RE: RE: RE: Further
)
Well, there's that...and the performance advantage ;-)
(Not directed at you, more through you...or, like was said in Spaceballs, "more to the side")