Windows S5R4 SSE2 power App 6.05 available
8 Oct 2008 13:58:16 UTC
Topic 13707
(moderation:
A SSE2 App for Windows can be found on the Power User's Apps page.
For this App to run your CPU must support SSE2 instructions.
This App has been built with an all-new build process using the MinGW/gcc compiler, which allows us to use the same code that's in the Linux SSE2 App.
Due to the great work of Oliver Bock (based on previous work of others) we should even get back useful stackdumps in case of a crash.
Primarily this is a field test for this new build process, I'd also expect significant speedup compared to the current standard Windows App.
This App is pretty recent and has undergone only very minimal internal testing, so prepare for the unexpected.
Only run this if you're sure of what you're doing
Happy crunching!
BM
BM
Windows S5R4 SSE2 power App 6.05 available
)
Here's an app_info.xml that should work. Due to the very different file structure Tasks already assigned to 6.04 will be finished with the 6.04 App, new tasks should be assigned to 6.05:
Replacing the last einstein_S5R4_6.04_windows_intelx86.exe by einstein_S5R4_6.05_windows_intelx86.exe could work (i.e. finishing Tasks assigned to 6.04 with 6.05), but I'm not even fully sure that the checkpoint files are compatible.
BM
BM
RE: RE: A SSE2 App for
)
Following an idea from Holger Pletsch which he got during the S4 results processing we are currently examining a way to reduce the computing power needed to search a certain area of parameter space. Also a bug in the current search code has been found and fixed, the effect this bug actually has on the results is also still under investigation. Currently it looks rather likely that this would at least affect the validation on Einstein@home, i.e. old and new Apps can't be run at the same time. BTW this bug fix is one reason for using the new build process.
If at least one of these issues applies, we will most likely cut the current S5R4 run short and start a new run "S5R5" with new Apps and a new workunit design (using the same data files, though). I'd consider it unlikely that I'll bring out new official "buggy" S5R4 Apps (6.05 is definitely an exception). Estimated timeframe for S5R5 (or a final decision on not to do it) is a few weeks (2-4). I'd expect S5R5 Windows Apps to have a similar switching mechanism like the current S5R4 Linux Apps (x87, SSE, SSe2), switching between three Apps that all have been built using the new process.
BM
BM
RE: RE: Looks like I had
)
I'm not sure about that. Once all the details has been decided, the implementation should take only a few days.
BM
BM
RE: One of my many
)
Can you point me to the result?
BM
BM
RE: RE: RE: One of
)
Where do you get that from?
On Einstein@home a file is marked as "validate error" (i.e. BOINC's validate_state = VALIDATE_STATE_ERROR) when something goes wrong checking the single result file (before comparing it to a different result of the same workunit). It could be that the file is not where the validator expects it to be, that it is empty (has zero length), can't be uncompressed properly, the uncompressed file contains something else than pure ASCII etc. etc. All these will end up as the same state in the DB. It might be that different web pages name that state slightly different, but AFAIK internally it's the same state in all cases.
The result file in question here has a broken directory entry in the zip archive header, while the zipped data itself looks ok. I've seen some of these problems with zipping on overclocked machines, my rough guess is that it depends on the die temperature of the ALU when the zipping happens. For now it doesn't look to me like a problem with the App.
BM
BM
RE: RE: Where do you get
)
Which properties exactly set this state of a result depends on the validator the project uses, so is usually highly specific to the project (edit: with the exeption of projects that use one of BOINC's validator examples like the "bitwise validator").
BM
BM
RE: RE: The result file
)
Depends on the tool / library you're using. InfoZip's unzip and the zlib-based zziplib (which we use in our current validator) refuse to unzip the file, gzip-based zcat skips the zip header anyway and reveals a result file that looks ok at first glance.
BM
BM
RE: Since SETI doesn't zip
)
That's right. For the next run S5R5 we're thinking of letting the BOINC Core Client do the compression (gzip) then. It would make the science App easier and possibly more reliable. However it only works with newer Core Clients (>= 5.8?), for older Clients this would be a penalty (bandwidth and storage) both for the Clients and our server. The current validator already can handle all three types (zip, gzip & plain text).
BM
BM
RE: RE: I had a look at
)
This is really surprising for a number of reasons
* The checkpoint is written successfully a lot of times and fails only occasionally, it looks like a race condition or similar - was there much disk activity from other programs (virus scanners, indexers) at the time of the errors?
* The program never fails to write the checkpoint to a temporary file, it just couldn't be renamed then to overwrite the older checkpoint a few times
* In case the new temporary file couldn't be renamed, at least the old file should still be there which, however, the App clearly couldn't find on restart.
This isn't a problem in our code, it could, however, be a problem in the BOINC library, or how it is compiled now.
Could you run a filesystem check on the partition where the BOINC directory is located? Just to be sure...
BM
BM
RE: It DOES seem to be
)
I don't think that this is much of a question. gcc is great, but until the MinGW people approve any gcc-4, we'll have to stick with their gcc-3.4, which gives slightly slower code than any gcc we use on Linux. At least we can now make use of the assembly code we wrote for gcc and throw out the MSC-specific stuff...
BM
BM