Windows Beta Test App 4.24 available
25 Jun 2007 15:37:30 UTC
Topic 13559
(moderation:
A new Windows App is available from our Beta Test Page.
Compared to the 4.23 Beta App this one fixes a bug in memory access that might be responsible for some client errors. Also the "symbol store" debugging feature should work now.
For the curious: You can provoke a "client error" (Breakpoint) by putting a file named "EAH_MSC_BREAKPOINT" into the BOINC directory (remember to remove it after testing!).
BM
BM
Windows Beta Test App 4.24 available
)
I'm pretty sure that the cross-platform validation problem neither has to do with the memory access bug we fixed, nor with a particular machine.
IMHO it is rather a problem of numerical differences between libraries or compilers that is triggered only by certain Workunits. It may be the actual frequency value or the data (files), e.g. a certain type of noise in particular frequency bands.
We're working on it.
BM
BM
RE: This may sound like a
)
There is no such thing as a silly question.
This is a very good question, and difficult to answer indeed.
"Science" (as it applies here) is based on mathematics, which is based on an ideal world: values are continuous, spaces are infinite etc.
Calculations performed on real-world machines (computers) are not like this: resources (memory, time) are limited, and so is precision, which means values are discrete. In this sense every (non-trivial real-number) calculation done on a computer is wrong wrt. the ideal model the implementation is based on. However, in many (hopefully most) cases the difference ("error") is neglectable.
Although every "computation" as mentioned is "wrong", i.e. differs from the mathematical idea, the difference itself varies between the systems the calculations are done with (CPUs, compilers, libraries etc.). A way to make all computations at least wrong in the same way is to set a standard for the way they are performed, independent of the properties named above. This was tried in IEEE 754.
Almost all "systems" have some way of enforcing calculations conforming to this standard. However, most modern processors have evolved beyond this standard and e.g. implemented ways to accelerate their own understanding of floating-point arithmetic, so enforcing "IEEE arithmetic" is still possible, but would noticeably slow down the computation compared to the systems "native" way.
So for us a way to ensure cross-platform compatibility would be to use IEEE arithmetic (and it would make the various CPUs truly comparable), but it would generally slow down the computation. For a project whose success (i.e. probability of detecting a gravitational wave) depends so much on the "computing power" (here: the number of computations done) this would have a severe impact, too.
Definitely not. In principle all results have been helpful, even though they didn't pass validation. We will need to adjust the App and/or the validator to make the good results pass validation, regardless of the platform they have been calculated on.
BM
BM
RE: Interesting questions
)
Fully true. There actually are two types of "signal injections" already done: "hardware injections" that actually affect the test masses of the detector (sometimes used for calibrations, too), testing the whole pipeline from detector to data analysis. There are "software injections", too, where fake pulsar signals are added by software to the data that has been recorded from the detector.
There should be more detailed descriptions of this in the S3 results report (available through a link from the front page).
This, however, is beyond the scope of a single workunit, and thus does not help for technically validating individual results.
BM
BM
RE: RE: For the curious:
)
Well, this is just for testing getting the symbols from the symbol store, so only if you're really curious. It will happen right at the beginning, so shouldn't waste computing time. You should probably set the project to "no new work" before you try this, and "allow more work" after you removed the file in order not to trash too many results. The result should look like this result, in particular you should find "PDB Symbols Loaded".
BM
BM
RE: BTW, Bernd, did you
)
Nope, I didn't notice before. Thanks for pointing out. I wrote a note to the person in charge of the scheduler (which sends out the cleanup requests).
BM
BM
I plan to make this App
)
I plan to make this App official in the next few hours, mainly to get a more useful info regarding the client errors. It looks like it will at least make things not worse than the current official App (apart from Intel-SSE2 machines, which will see a small penalty of around 7%, but caugth up by the AMDs).
BM
BM
It turns out there are a
)
It turns out there are a number of issues that lead to these cross-platform validation problems, some of which have been addressed recently, some we're still digging for. Solving these problems will probably require both a new validator and a complete set of Apps. I am confident that we will have all these pieces together next week.
BM
BM
RE: That's really great
)
I already have some code that should speed up computation significantly, but with the present issues it's simply impossible to validate it.
BM
BM
RE: Is it as simple as
)
Yes it is.
BM
BM
RE: The notice on the Home
)
Thanks. However, changing news items later is difficult, it causes trouble not on our site, but on the sites getting the news from xml or rss feeds.
BM
BM