MacOS X Intel S5R3 App 4.10 available for Beta Test
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4,305
Credit: 248,843,500
RAC: 34,078
23 Oct 2007 8:27:03 UTC
Topic 193263
(moderation:
A new MacOS X Intel App is available from our Beta Test Page.
This App (actually this compiler, which is Apple's version of gcc) is the first one where I could get the linear sin/cos interpolation to work reliably even on boundary conditions. It should be quite a bit faster than the one used in previous Apps. However it still bears the risk of being not accurate enough, therefore I'd like to test it on a larger scale. The risk is not in possible client errors, but the results might fail validation.
The BOINC library version that this App is linked with is meant to solve the "hang" problem that has been observed primarily on MacOS Apps.
Beyond that this App features the advances that have been made in the code development of S5R3 as shown in the Windows and Linux Apps (single-file checkpointing, checkpoint syncing w. opt-out (see 4.15 Beta App thread), FP exceptions instead of finite() checks).
As we haven't seen these nasty floating-point errors ("Input domain errors") on MacOS (*), I decided to put in a vectorized SSE version of the "hot loop", which should give additional speedup.
This App is an App as fast as I can build today (fasten seat belts!), and I hope to get the other Apps as fast as this. However the improvements need to be tested, and this platform looks like the best one to do this on. MacOS Intel has been the most reliable platform by far on this project (since S5R2), let's see if it stays like this.
Transition from 4.04 should be smooth in the sense that the app_info.xml has an entry for the current official 4.04 App. I.e. the 4.04 will be used to finish the tasks already assigned to it, and new tasks will be assigned to and crunched with 4.10 (Checkpoints are incompatible between 4.04 and 4.10).
Please test and report!
BM
(*) I'm still not sure why this is. It might be that Apple not only controls the OS, but also the hardware it runs on, and thus the hardware failures are less likely to occur compared to cheaply built PCs. Another possibility is that having no CPU older than Intel Core 2 the compiler can rely on SSE/SSE2 and hardly makes use of the x87 FPU instructions / execution environment at all.
BM
MacOS X Intel S5R3 App 4.10 available for Beta Test
)
Started testing on this host.
Will run parallell with SETI for a bit then Einstein alone for a bit.
Anders n
My first 4.10 will begin in 8
)
My first 4.10 will begin in 8 hrs or so.
I suspect (not sure, tho) that the variation in runtime that we've see in S5R3 so far will be even more pronounced in this new MacOS version, so please be neither too enthusiastic nor too disappointed by the first results, it will take some averaging over several results to find out just how much faster this new app is.
CU
Bikeman
Looks like it dropped my run
)
Looks like it dropped my run times from 29-30,000 to about 26-27,000. None have validated yet how ever.
Looking good so far. Times
)
Looking good so far.
Times seem to have dropped about 2500 sek. and 1 just validated OK.
Anders n
Hi! I've got two results
)
Hi!
I've got two results crunched now, and one is already validated .
http://einsteinathome.org/task/87920220.
And YES, this one is fast. As I said earlier, it will take many more results to estimate the average speedup, but this one seems to be more than 25% faster, probably more.
CU
H-BE
This looks exciting. I think
)
This looks exciting. I think I'll put 4.10 on my dual Quaddy Mac Pro. Seems like the app is sound enough. And the speed increase looks nice too. ;)
RE: Looks like it dropped
)
It looks like validation is happening as it should. I like this app!
RE: RE: Looks like it
)
I now have 3 out of 3 results validated.
CU
Bikeman
My mac mini had two results
)
My mac mini had two results complete and 1 validated ok already with 4.10 Prior low time was ~51000 sec and the new app dropped it to ~43,000. Sweet!!!
RE: My mac mini had two
)
Nice!
Percentage-wise, the drop in the "low-time" should be greatest, while the "high-times" see (relatively) less speed-up, but similar absolute reductions in runtime (for the same frequency band). Just a rule of thumb, tho.
CU
Bikeman