Inefficient science app for MacOS X
Anonymous
11 Apr 2006 10:41:46 UTC
Topic 13316
(moderation:
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
Inefficient science app for MacOS X
)
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
Despite the problems I posted
)
Despite the problems I posted the new MacOS App for public beta testing, especially to get some feedback. See this thread.
BM
BM
On Intel machines we
)
On Intel machines we currently use assembly code that avoids this problem. I'm afraid I'll not be able to do something about these invalid results from PPC code for the last remaining Workunits of the S4 run (estimated for one month), but this shouldn't occur in the next run anymore. A code that includes measurements to avoid these invalid results with the current workunits wouldn't run faster than the AltiVec code that's in the current official PPC Mac App.
BM
BM
I'll do what I can. But you
)
I'll do what I can. But you know, manpower is limited, and the light of the PPC CPU is rather fading with Apples latest decisions, so the PPC code, in particualr the PPC-specific code doesn't have the highest priority for Einstein@Home. It will, however, definitely benefit from changes to the source code that aren't specific to a certain architecture, so there is still room for improvements. If I find the time, I'll be happy to incorporate what I've learned writing the Intel assembler code into a PPC App - but I can't promise right now neither when this will happen nor that it will happen at all.
BM
BM