MacOS X Intel S5R3 App 4.10 available for Beta Test
23 Oct 2007 8:27:03 UTC
Topic 13618
(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
)
It's not a matter of me or effort, but of the algorithm.
The part of the program that is similar to what we were using previously (you'll find the word "Fstat" in the function names in Shark) performs some identical operations over a number of similar input items that are arranged in a way that allows parallel loading. The <50% that it's using is already the result of aggressive optimization, in S5R2 it took about 80% of the total CPU time.
The other part that is rather new (look for "Hough") has a some data-dependent branches; the operations performed there aren't completely identical, and thus not easy to parallize. In addition the data structures used there don't support parallel access.
At some point I'll take a closer look at this part of the code, and maybe even rewrite it completely using data structures that allow for more efficient computing. But this will take a while, and currently I don't even have the time to start with it.
BM
BM
IIRC the size of the matrices
)
IIRC the size of the matrices varies with frequency. The update is data dependent. In principle the matrix is a "Hough Plane" or "Hough space graph" as called in the Wikipedia article about the Hough transform. There is a lookup table (cache) associated to some calculations done before updating the map. The number of hits / misses to this cache btw. is responsible for the run-time variation we see for workunits with the same number of templates. The values added are not binary (1 or 0), but involve a weight factor.
The "new" code is currently undergoing some internal review and validation process. Though I doubt that serious issue arise, it may still be changed.
I guess its more efficient right now to concentrate on getting the remaining bugs out of the rest of the code and get the SSE optimization into the other architectures.
BM
BM
RE: Could you make an
)
I moved this over to the Client Errors of S5R2/S5R3 Apps thread in the Problems & Bug reports board.
BM
BM
We get some -185 ("can't
)
We get some -185 ("can't start App") errors from 8-core Macs that have a shmem message in stderr_out. The problem is that the number of shared memory segments on MacOS (actually FreeBSD, I believe) is limited to 8. The Client uses shared memory to communicate with the Apps, so if there is anything else than BOINC that uses shared memory running on such a system, you get into trouble on one or the other end.
There is a way around this, but this will require a new App (and a recent Core Client)
BM
BM
RE: @Bernd - unless you
)
A "validate error" means that the invalidity of a result can be determined from the result itself without comparison to other results of the same WU. This can be a technical problem such a as a missing result file, but also happens if the file can't be unzipped or (in Einstein@home case) contains unreasonable values (e.g. NaNs). I'll see when I'll find the time to look into this particular case.
BM
BM
RE: Got my first error with
)
This is really an interesting one. It's not your fault, and not that of the BOINC backend. It requires a bit more digging through the code than I have time for right now, but it looks like some problem that was fixed a while ago in the Windows and Linux Apps. I should make a new MacOS Intel App that incorporates these fixes, but I doubt I'll come to it the next two weeks.
BM
BM
RE: I should make a new
)
Done. Please use that instead.
BM
BM