I'm running 4.26 under Windows XP Pro 64-bit edition, BOINC v5.10.13 (also 64 bit build)....
....only crunched one WU with it so far and there was absolutely no speedup in crunching time over the stock app....
Ok, next WU crunched fully with 4.26 has finished and validated, and again, no apparent speedup over the stock app.
This is on an AMD64 3400+ BTW.
Furthermore, with the 4.26 app, when an Einstein WU is running it keeps control of the system until it reaches about 51% before allowing other processes to run. Then when the Einstein WU restarts it again keep control until it finishes. :-(
Ok, next WU crunched fully with 4.26 has finished and validated, and again, no apparent speedup over the stock app.
....
I'm switching back to the stock app.
Hi Pete,
If you think there is no speedup you are not taking into account the cyclic nature of crunch times.
If you do account for it you will find that you should be comparing taskID 91396174 crunched with the new app with taskID 91138477 crunched with the old app, since these two are at virtually identical points on the cycle. If you do that comparison you will see a 10% speedup.
The logic behind why these two taskIDs are the appropriate ones to compare is explained here.
If you think there is no speedup you are not taking into account the cyclic nature of crunch times....
You misunderstand my message.
I didn't switch back to the stock app because of the lack of any apparent speedup. Two work units are far too few to form an accurate opinion.
No, I switched back because of the test applications' refusal to relinquish the CPU until it had completed at least 50% of the WU...! And then it would insist on completing the WU in one go when restarted, this sort of "hogging" of my CPU by one project is unacceptable.
If it wasn't for that I'd have persevered with v4.26.
OK, but in my defense you did mention two separate points, no speedup and hogging the CPU, so I figured you would probably mention the most important factor first :).
I only dealt with the first factor because the people who read these messages are easily put off testing a new beta if they think it doesn't have any improvement. I wanted to make sure that the readers know there is a good improvement.
Quote:
I didn't switch back to the stock app because of the lack of any apparent speedup. Two work units are far too few to form an accurate opinion.
Actually you had more than enough data for me to come up with an accurate assessment of a speedup of close to 10%.
Quote:
No, I switched back because of the test applications' refusal to relinquish the CPU until it had completed at least 50% of the WU...! And then it would insist on completing the WU in one go when restarted, this sort of "hogging" of my CPU by one project is unacceptable.
Sounds like you are punishing the app for the sins of BOINC :).
The app has NO control over when it does or doesn't run. That function is entirely up to BOINC and if it were an ongoing problem, the old app, under the control of BOINC, would be behaving exactly the same way. BOINC ultimately always honours your resource shares. If we don't trust in that we should pack up now and go home. There are reasons why BOINC may have decided it needed to finish off that EAH task without relinquishing the CPU. Possible deadline trouble (real or imaginary) immediately springs to mind. However the debt would have been repaid without putting the poor old EAH app to the sword :).
Actually you had more than enough data for me to come up with an accurate assessment of a speedup of close to 10%.
If Ensor (Pete) is not seeing an increase in performance with 4.26, he is the only person posting who is not.
It seems he made the mistake of comparing a result at a higher natural runtime that was done with 4.26 to a lower natural runtime that was done with 4.15. 4.26 was not able to sufficiently reduce the amplitude / rate of change of the natural cyclic variation for it to appear "faster", and if I am right about what he compared, 4.26 was technically about 2000 seconds "slower", but the comparison is invalid because of the differing points in the variation cycle.
A better comparison would be to look at h1_0737.50_S5R2__8_S5R3a that was run with 4.26 against h1_0737.50_S5R2__105_S5R3a that was run with 4.15. The result run with 4.26 took 53805.30, while the task run with 4.15 took 59250.30, showing that 4.26 is most definitely faster than 4.15.
In any case, 4.26 or something based off of it will most likely soon become the stock application, so resistance is futile... ;-)
@Ensor - bud, trust me, it's faster. I've been commenting on the speed problems for months now...so I know it's faster...
If Ensor (Pete) is not seeing an increase in performance with 4.26, he is the only person posting who is not.
I think I've seen a couple of others that were a little duobtful.
In Pete's defense, it really isn't obvious as to which tasks should be compared and the huge scatter in crunch times is quite frustrating to deal with.
Quote:
A better comparison would be to look at h1_0737.50_S5R2__8_S5R3a that was run with 4.26 against h1_0737.50_S5R2__105_S5R3a that was run with 4.15. The result run with 4.26 took 53805.30, while the task run with 4.15 took 59250.30, showing that 4.26 is most definitely faster than 4.15.
Those are exactly the two tasks I linked to in my message to Pete several posts earlier in this thread and they do indeed provide a quite good comparison.
Quote:
In any case, 4.26 or something based off of it will most likely soon become the stock application, so resistance is futile... ;-)
I reckon you're right there too :). -- unless of course Bernd manages to get the latest version of the Microsoft compiler and this version actually does manage to compile the app the way he needs. He might delay things a little in that event.
If Ensor (Pete) is not seeing an increase in performance with 4.26, he is the only person posting who is not.
I think I've seen a couple of others that were a little duobtful.
In Pete's defense, it really isn't obvious as to which tasks should be compared and the huge scatter in crunch times is quite frustrating to deal with.
True enough... I got to thinking though, did 4.26 decrease the amplitude any, or did it just shift the whole "waveform" (as it were) downward?
... did 4.26 decrease the amplitude any, or did it just shift the whole "waveform" (as it were) downward?
That's a very good point and one that only the prodigious data gatherers like Peter and Richard (and perhaps Tony now that he is active here) will be able to answer after they have populated out some full cycles. My fastest machine produces less than 3 results per day so it will be a while before I have enough history to check through. I've just assumed that the waveform is displaced evenly so it will be very interesting to see if that assumption is valid or not.
... did 4.26 decrease the amplitude any, or did it just shift the whole "waveform" (as it were) downward?
That's a very good point and one that only the prodigious data gatherers like Peter and Richard (and perhaps Tony now that he is active here) will be able to answer after they have populated out some full cycles. My fastest machine produces less than 3 results per day so it will be a while before I have enough history to check through. I've just assumed that the waveform is displaced evenly so it will be very interesting to see if that assumption is valid or not.
My data-gathering was a bit of a one-off while I was getting the measure of a new Q6600 - it just happened to coincide with an interesting period in the evolution of S5R3. The quaddies now have something more like the recommended mix of BOINC projects.
I don't think I'll start another run until/unless Bernd decides to make 4.26 official - but if it's going to be around for a while, I agree it would be worth a go to answer Brian's question.
Sorry Gary, I started too late to get enough "old" data to make a comparison. Although I might contribute in a meaningful way later (following in the footsteps of Richard and Archae86)
RE: I'm running 4.26 under
)
Ok, next WU crunched fully with 4.26 has finished and validated, and again, no apparent speedup over the stock app.
This is on an AMD64 3400+ BTW.
Furthermore, with the 4.26 app, when an Einstein WU is running it keeps control of the system until it reaches about 51% before allowing other processes to run. Then when the Einstein WU restarts it again keep control until it finishes. :-(
I'm switching back to the stock app.
TTFN - Pete.
RE: Ok, next WU crunched
)
Hi Pete,
If you think there is no speedup you are not taking into account the cyclic nature of crunch times.
If you do account for it you will find that you should be comparing taskID 91396174 crunched with the new app with taskID 91138477 crunched with the old app, since these two are at virtually identical points on the cycle. If you do that comparison you will see a 10% speedup.
The logic behind why these two taskIDs are the appropriate ones to compare is explained here.
Cheers,
Gary.
Hi Gary, RE: If you
)
Hi Gary,
You misunderstand my message.
I didn't switch back to the stock app because of the lack of any apparent speedup. Two work units are far too few to form an accurate opinion.
No, I switched back because of the test applications' refusal to relinquish the CPU until it had completed at least 50% of the WU...! And then it would insist on completing the WU in one go when restarted, this sort of "hogging" of my CPU by one project is unacceptable.
If it wasn't for that I'd have persevered with v4.26.
TTFN - Pete.
RE: You misunderstand my
)
OK, but in my defense you did mention two separate points, no speedup and hogging the CPU, so I figured you would probably mention the most important factor first :).
I only dealt with the first factor because the people who read these messages are easily put off testing a new beta if they think it doesn't have any improvement. I wanted to make sure that the readers know there is a good improvement.
Actually you had more than enough data for me to come up with an accurate assessment of a speedup of close to 10%.
Sounds like you are punishing the app for the sins of BOINC :).
The app has NO control over when it does or doesn't run. That function is entirely up to BOINC and if it were an ongoing problem, the old app, under the control of BOINC, would be behaving exactly the same way. BOINC ultimately always honours your resource shares. If we don't trust in that we should pack up now and go home. There are reasons why BOINC may have decided it needed to finish off that EAH task without relinquishing the CPU. Possible deadline trouble (real or imaginary) immediately springs to mind. However the debt would have been repaid without putting the poor old EAH app to the sword :).
Cheers,
Gary.
RE: Actually you had more
)
If Ensor (Pete) is not seeing an increase in performance with 4.26, he is the only person posting who is not.
It seems he made the mistake of comparing a result at a higher natural runtime that was done with 4.26 to a lower natural runtime that was done with 4.15. 4.26 was not able to sufficiently reduce the amplitude / rate of change of the natural cyclic variation for it to appear "faster", and if I am right about what he compared, 4.26 was technically about 2000 seconds "slower", but the comparison is invalid because of the differing points in the variation cycle.
A better comparison would be to look at h1_0737.50_S5R2__8_S5R3a that was run with 4.26 against h1_0737.50_S5R2__105_S5R3a that was run with 4.15. The result run with 4.26 took 53805.30, while the task run with 4.15 took 59250.30, showing that 4.26 is most definitely faster than 4.15.
In any case, 4.26 or something based off of it will most likely soon become the stock application, so resistance is futile... ;-)
@Ensor - bud, trust me, it's faster. I've been commenting on the speed problems for months now...so I know it's faster...
RE: If Ensor (Pete) is not
)
I think I've seen a couple of others that were a little duobtful.
In Pete's defense, it really isn't obvious as to which tasks should be compared and the huge scatter in crunch times is quite frustrating to deal with.
Those are exactly the two tasks I linked to in my message to Pete several posts earlier in this thread and they do indeed provide a quite good comparison.
I reckon you're right there too :). -- unless of course Bernd manages to get the latest version of the Microsoft compiler and this version actually does manage to compile the app the way he needs. He might delay things a little in that event.
Cheers,
Gary.
RE: RE: If Ensor (Pete)
)
True enough... I got to thinking though, did 4.26 decrease the amplitude any, or did it just shift the whole "waveform" (as it were) downward?
RE: ... did 4.26 decrease
)
That's a very good point and one that only the prodigious data gatherers like Peter and Richard (and perhaps Tony now that he is active here) will be able to answer after they have populated out some full cycles. My fastest machine produces less than 3 results per day so it will be a while before I have enough history to check through. I've just assumed that the waveform is displaced evenly so it will be very interesting to see if that assumption is valid or not.
Cheers,
Gary.
RE: RE: ... did 4.26
)
My data-gathering was a bit of a one-off while I was getting the measure of a new Q6600 - it just happened to coincide with an interesting period in the evolution of S5R3. The quaddies now have something more like the recommended mix of BOINC projects.
I don't think I'll start another run until/unless Bernd decides to make 4.26 official - but if it's going to be around for a while, I agree it would be worth a go to answer Brian's question.
Sorry Gary, I started too
)
Sorry Gary, I started too late to get enough "old" data to make a comparison. Although I might contribute in a meaningful way later (following in the footsteps of Richard and Archae86)