To change the precision needs very big circumspection. Usually the validator gives 0 credit to the more accurate algorithms, because the results of the two others are same (but less accurate).
Thank you dear Akos for the information. For some unknowing person like me it is difficult to understand why these optimisation do take a while. I keep my fingers crossed that finding the solution will not cause too much hassle.
So, well, here I am reporting my results with the 4.55er:
Dual HT Xeon machine running SuSE OSS 10.0 with standard installation;
zero granted credit: 1
granted credit: virtually all (apart from the one above)
speed-up: ~25%
While it's not the 80% speed up pulled out the hat for the Windows boxes, at least it is some considerable amount. Thanks for all the effort; it really helps motivating to cough up for the electricity bill.
:
your thoughts - the ways :: the knowledge - your space
:
I'm running 4.50 (Win) and 4.55 (Lin) each on one of my boxes, and
haven't had any problems so far. No crashes, no invalid results.
The Win-Box (AXP 2600, W2k, 5.13) has a performance boots of 33%
(10k sec instead of 15k sec, same WU) and around 40 results, none invalid.
The Lin-Box (A64 3200, SuSE 9.2, 5.14) also has a boost, but I cannot
count it, because at the point I switched the app, it discarded the old
WU and downloaded a new one. But with this one it can finish one task
in under 1h, and that has never happened before :-). The Lin-Box has
about 60 results, none invalid.
I'll keep on using the betas on these two machines, but will stick to the
official apps on the rest.
As soon as the opt. apps exit beta-status I have to manually change only these two, as the rest will get the new release automatically.
I have some invalid results too
[...]
An important point is, that all invalid results are procced by old Athlon 64 processors with Clawhammer Core (130nm).
My newer Dual Core Toledo and Winchester have done only valid results.
My A64 3200 that runs the beta-app for linux is a Clawhammer...
no problems so far...
ey, since a fortnight has passed, I was wondering if there are any news on that front? Bernd, have you managed to integrate akosf's suggestion or are there more obstacles to it?
I have just come back from two weeks travel. Having looked into (some of) the invalid results from the 4.55 App I found that the sin/cos precision is probably not the reason for them being invalid. I'm looking into this.
I have tested the 4.55 Linux app on a Celeron 433 MHz (Mendocino core, no SSE). And the results are embarrassing for the Linux app in comparison to akosf Win app (meaning the C41). While the Linux app needs ~63500 secs per unit, akosf app is done in around 33500 secs on average, which is nearly twice as fast. Nevertheless it is nice to see some speedup with the Linux apps. Keep up to great work!
This problem seems to be unavoidable with that whole category of code, regardless of the vector unit used - may it be SSE, AltiVec or VIZ - everything that at a certain point is limited to single precision arithmetic.
I'm currently trying to find out how important the error is scientifically. If it turns out to be neglectable, we would still have to change the validator quite a bit - it's not just tuning of parameters, but adding new features to it - to make it pass such results.
For the x86-based platforms I intend to publish an App rather soon that has been partly coded in assembler and shouldn't have that problem - hopefully.
RE: To change the precision
)
Thank you dear Akos for the information. For some unknowing person like me it is difficult to understand why these optimisation do take a while. I keep my fingers crossed that finding the solution will not cause too much hassle.
So, well, here I am reporting my results with the 4.55er:
Dual HT Xeon machine running SuSE OSS 10.0 with standard installation;
zero granted credit: 1
granted credit: virtually all (apart from the one above)
speed-up: ~25%
While it's not the 80% speed up pulled out the hat for the Windows boxes, at least it is some considerable amount. Thanks for all the effort; it really helps motivating to cough up for the electricity bill.
:
your thoughts - the ways :: the knowledge - your space
:
Hi, I'm running 4.50 (Win)
)
Hi,
I'm running 4.50 (Win) and 4.55 (Lin) each on one of my boxes, and
haven't had any problems so far. No crashes, no invalid results.
The Win-Box (AXP 2600, W2k, 5.13) has a performance boots of 33%
(10k sec instead of 15k sec, same WU) and around 40 results, none invalid.
The Lin-Box (A64 3200, SuSE 9.2, 5.14) also has a boost, but I cannot
count it, because at the point I switched the app, it discarded the old
WU and downloaded a new one. But with this one it can finish one task
in under 1h, and that has never happened before :-). The Lin-Box has
about 60 results, none invalid.
I'll keep on using the betas on these two machines, but will stick to the
official apps on the rest.
As soon as the opt. apps exit beta-status I have to manually change only these two, as the rest will get the new release automatically.
RE: I have some invalid
)
My A64 3200 that runs the beta-app for linux is a Clawhammer...
no problems so far...
http://einsteinathome.org/host/512894/tasks
RE: ey, since a fortnight
)
I have just come back from two weeks travel. Having looked into (some of) the invalid results from the 4.55 App I found that the sin/cos precision is probably not the reason for them being invalid. I'm looking into this.
BM
BM
RE: My A64 3200 that runs
)
Ok, now I've an invalid result on it (my very first of 67).
http://einsteinathome.org/task/26292388
Still no problems on the 4.50-app on Win.
I have tested the 4.55 Linux
)
I have tested the 4.55 Linux app on a Celeron 433 MHz (Mendocino core, no SSE). And the results are embarrassing for the Linux app in comparison to akosf Win app (meaning the C41). While the Linux app needs ~63500 secs per unit, akosf app is done in around 33500 secs on average, which is nearly twice as fast. Nevertheless it is nice to see some speedup with the Linux apps. Keep up to great work!
7 results completed
)
7 results completed sucessfully using 4.55, no failures and 3 canonical.
Personally I think the speed up is great :)
Need Help? Try the excellent Unofficial BOINC Wiki!
We are the BOINC. Prepare to be assimilated.
'anthrax beats WinXP' - The Register
Found some more invalid
)
Found some more invalid results:
27178378
27268060
27389445
Michael
Team Linux Users Everywhere
I've been hit with a few more
)
I've been hit with a few more invalids.
26729550
27375994
27375988
Three of the 33 completed tasks currently listed are invalid.
Any idea when a solution might be implemented?
Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
Douglas Adams (1952 - 2001)
RE: Any idea when a
)
I'm working on it.
This problem seems to be unavoidable with that whole category of code, regardless of the vector unit used - may it be SSE, AltiVec or VIZ - everything that at a certain point is limited to single precision arithmetic.
I'm currently trying to find out how important the error is scientifically. If it turns out to be neglectable, we would still have to change the validator quite a bit - it's not just tuning of parameters, but adding new features to it - to make it pass such results.
For the x86-based platforms I intend to publish an App rather soon that has been partly coded in assembler and shouldn't have that problem - hopefully.
BM
BM