Inefficient science app for MacOS X
11 Apr 2006 10:41:46 UTC
Topic 191069
(moderation:
The science application for E@H is, compared to the SETI@Home Alpha 5.2, extremely inefficient. When you compare the Credits/hour data between those two applications it turns out, that the SETI app produces more then twice as much data then the E@H science app: Pending Credits for BOINC Projects
Any optimization on the horizon?
P.S. Officially the E@H science app is already Altivec-optimized. However, it's still slow.
Inefficient science app for MacOS X
)
Now the shoe is on the other foot, you start complaining. ;-)
Andy
We've started complaining
)
We've started complaining long ago but nobody cares to listen....
And with the advent of the Int(el)-cheapo Macs, I seriously doubt there will ever be another revision of the Altivec-optimised science apps.....
I'm curious how you judge the
)
I'm curious how you judge the efficiency of an App - the data used and produced on Einstein@Home has nothing to do with that used on SETI, and nor has any of the algorithms used there, or the length of the Workunits. SETI is mainly doing FFT, which is an algorithm that is well understood and for which highly optimized libraries are available for each CPU. Einstein@Home is not like that.
We've been working with experienced programmers from Apple to make the AltiVec version as fast as we can, and of all official Apps it makes the most of every clock cycle of a CPU.
Unlike on the other platforms I couldn't build anything that ran faster than the current AltiVec version on a PPC Mac (G4 or G5) - until less than a week ago. The vector code I wrote and am currently testing in the Linux App has been reported to be around 20% faster, that's all. And requiring a newer compiler I still have problems building an App with that code that still runs on 10.3 (Panther).
No, guys, you have not been forgotten, not from a Macaddict like me. But I'm on the road right now and it will take some time until I get back to my development machines.
BM
BM
RE: I'm curious how you
)
Bernd,
thanks for the feedback!
RE: RE: I'm curious how
)
Yes Thanks Bernd,
Looking forward to getting the next version of the G5 app with the new optimizations built in.
Rand
RE: No, guys, you have not
)
Hi Bernd,
any news on the new app?
My current vector code has
)
My current vector code has either a minor bug or a numerical instability, that shows up as occasional invalid results of the 4.55 Linux App. I want to have this fixed before I do anything else with that code, like using it for other platforms.
BM
BM
RE: a numerical
)
Sorry for my bad English - but what's that? :-)
RE: RE: a numerical
)
A fancy phrase for a calculation that can loose enough precision to screw up the result.
For example, using 4 decimal digits of precision, and granting that this is a contrived example to make my point
((4.000/(2.000-.00015))-2.000)*2000 =3.022.... according to the windows calculator.
doing it with only 4 digits of precision though you get:
((4.000/(2.000-.0001500))-2.000)*2000 =
((4.000/(1.999))-2.000)*2000 =
(2.001-2.000)*2000 =
(.001)*2000 = = 2.000
This is an error of 33%!
In the real science app the error's probably much smaller but compounds over 1000's of iterations into something eventually becomes large enough to break something.
RE: P.S. Officially the
)
I've tested my G5 1.9 against a P4 2.4A (on Akosf's optimised S41.06 client) on the same WU, my G5 was smoked; my P4 completed the WU in less than half the time it took on the G5.