Ideally aimed at Berdt but others in the know (Bikeman or Gary) feel free to answer.
Does this mean we might get a SSE3 or even a SSSE3 optimized app (or heaven forbid a SSE4.1 app)? Although anything above SSE3 will be useless to the AMD guys, and none of my machines are SSE4.1 capable.
Will this version, if successful, get merged into the standard app whenever the next standard app comes along, or maybe even become the next standard app?
I compared my .xml to the message 89835, and the .xml I downloaded seems to have this information already in it.
I'm not sure how you compared the two but the file I posted is quite different to the file contained in the zip archive - unless someone has rejigged the zip archive since I downloaded it a few hours ago :-).
I downloaded the archive at 9:47 UTC, and it only had the 605 version specification in it. I did the block duplication and edit to 604, and it's running the cached (and part crunched) tasks without problem. Be a while (possibly a couple of hours, if I can prevent it switching to another project) before I can check validation.
A small cosmetic note: the app_info.xml file uses Linux-format line breaks, which isn't Windows-friendly (Notepad displays all the text as one long line). Wordpad soon sorts that out, but check with Notepad that you haven't introduced any stray formatting. And don't even think of using any more bloated word processor....
For this App to run your CPU must support SSE2 instructions.
Bernd,
Are you intending to build a version for SSE capable hosts and then use the "switcher app" mechanism to determine the host capabilities so that SSE hosts like AMD Athlon XP and Tualatin PIIIs can also enjoy a speedup?
If so, any ETA on when this might be available?
Thanks.
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.
Well I just got mine installed with a clear cache of work, though there seems to be a huge amount of datafiles in the directory.
#1- I'm assuming at some point in time that those we either be used by 6.05 or called to be deleted from the server.
#2- Since I had no work to process I just dropped Bernd's app_info.txt file in and its working its way through a workunit now. Should we be seeing the additional -1 files or will it only be 1 file per workunit? Examples:
... A small cosmetic note: the app_info.xml file uses Linux-format line breaks, which isn't Windows-friendly (Notepad displays all the text as one long line). Wordpad soon sorts that out, but check with Notepad that you haven't introduced any stray formatting.
Yes, the app_info.xml file stored in the zip archive does have Unix style line breaks (the single character Unix newline) as opposed to the two character combination of (carriage return, line feed) which is used in MS-DOS text files. As you note, if you read in the file with Wordpad and immediately "save as", the new file you create has the newlines converted to and now Notepad can happily read the file, showing the correct formatting.
Quote:
And don't even think of using any more bloated word processor....
Actually, a very good editor to use instead of Windows Notepad is a freeware program called Notepad2 which I've used for years. It's very simple to use and it has some cool editing features that are lacking in Notepad. One of it's many useful settings is the ability to read in either Windows or Unix text files, automatically showing the proper formatting, and to write out text files with whatever style line ending you need. And it doesn't introduce any stray formatting :-).
... if you read in the file with Wordpad and immediately "save as", the new file you create has the newlines converted to and now Notepad can happily read the file, showing the correct formatting.
Actually, if you "Open with..." Wordpad, and simply click the 'Save' icon (floppy disk symbol), the format conversion is done in one click and you don't have to worry about new file names.
... 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.
OK, sounds good. Thanks very much for the update.
I'm sure everybody is looking forward to the time when the full range of Windows apps are performing similarly to their Linux counterparts.
Well I just got mine installed with a clear cache of work, though there seems to be a huge amount of datafiles in the directory.
Not quite sure what you mean by this statement. You always get around 14 to 18 large data files whenever you set up a host to crunch E@H tasks. Once you have those data files, you can potentially get quite a large number of tasks over quite a long period that all depend on the same set of data files. You get exactly the same set of data files irrespective of the version of the science app you will be using.
Quote:
#1- I'm assuming at some point in time that those we either be used by 6.05 or called to be deleted from the server.
Each "task" that is sent to you is actually a set of parameters for the science app to use in processing the data in the large files that were previously sent to you. While you continue to be sent tasks for the same frequency band, you won't normally see changes in the large data files. If the scheduler decides to "step up" to the next frequency band, you will normally see a request to delete 2 of the large data files (now "used up") whilst 2 new data files will be downloaded and added to the remaining pool.
When all the available tasks are allocated for a particular set of large data files, the server will take care of deleting all the "used up" files.
Quote:
#2- Since I had no work to process I just dropped Bernd's app_info.txt file in and its working its way through a workunit now. Should we be seeing the additional -1 files or will it only be 1 file per workunit? Examples:
The files I imagine you are trying to describe don't exist for the 6.05 version science app because the 6.05 app is confined only to hosts which support SSE2 (or higher) instructions. The _0, _1, etc, terminology has got nothing to do with data files or tasks or workunits. It relates to versions of the science app which have been purpose built to be able to handle different CPU capabilities, such as no SSE, SSE only, SSE+SSE2, etc. With the standard app (like 6.04) there is a "switcher app" which determines the capabilities of your CPU and then runs the appropriately built version of the science app for your CPU. None of this applies to 6.05 because this new version is only applicable to CPUs that have at least SSE2 instructions.
So the answer to your question is that (for 6.05) you wont be seeing any extra versions of the science app that have _0 or _1 etc tags in their name. I trust you did confirm the capabilities of your CPU before you threw version 6.05 into the mix? :-).
My initial guess is that on this host for this type of work the new ap makes the host about 17% more productive, or that it takes about 85% as long as before.
With ten returned results from this Q6600 in hand, I'll update these estimates.
The mean CPU time of the ten 6.05 results is 25066 seconds, compared to 30248 seconds for a reference sample of twenty-seven results on 6.04 from the same small range of sequence numbers in very closely similar frequencies.
So this update is within Brian's estimate range, 21% productivity improvement, or for those who prefer the execution ratio, 83% as long to finish a result.
I'll update the gif pointed to by my message 89807, and add to this message similar gifs for two other hosts:
Stoll3 is an E6600 Duo running a very similar configuration to Stoll4, my Q6600. However clearly something has disrupted the consistency of its results in the past-possibly my wife's Solitaire game.
Toshiba1 is a laptop which also has a Conroe-class processor, a U7700 running 1.33 GHz, but restricted for BOINC to one cpu.
Bottom line--on this set of Conroe-class Windows XP SP3 hosts 6.05 is a considerable improvement on the Windows 6.04 ap in performance, but not close to the standard distribution Linux ap. More importantly, I've not seen any obvious bad behaviors yet. As I happened to be in the lucky side of the quorum distribution lottery, I've already got validation for all six results from Stoll3 (4 pure shown here, 2 mid-course changed from 6.04), and eleven pure results from Stoll4. Validation on Toshiba1 will have to wait for better luck on the quorum partner front.
Ideally aimed at Berdt but
)
Ideally aimed at Berdt but others in the know (Bikeman or Gary) feel free to answer.
Does this mean we might get a SSE3 or even a SSSE3 optimized app (or heaven forbid a SSE4.1 app)? Although anything above SSE3 will be useless to the AMD guys, and none of my machines are SSE4.1 capable.
Will this version, if successful, get merged into the standard app whenever the next standard app comes along, or maybe even become the next standard app?
Cheers
BOINC blog
RE: RE: I compared my
)
I downloaded the archive at 9:47 UTC, and it only had the 605 version specification in it. I did the block duplication and edit to 604, and it's running the cached (and part crunched) tasks without problem. Be a while (possibly a couple of hours, if I can prevent it switching to another project) before I can check validation.
A small cosmetic note: the app_info.xml file uses Linux-format line breaks, which isn't Windows-friendly (Notepad displays all the text as one long line). Wordpad soon sorts that out, but check with Notepad that you haven't introduced any stray formatting. And don't even think of using any more bloated word processor....
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
Well I just got mine
)
Well I just got mine installed with a clear cache of work, though there seems to be a huge amount of datafiles in the directory.
#1- I'm assuming at some point in time that those we either be used by 6.05 or called to be deleted from the server.
#2- Since I had no work to process I just dropped Bernd's app_info.txt file in and its working its way through a workunit now. Should we be seeing the additional -1 files or will it only be 1 file per workunit? Examples:
einstein_S5R$_6.05_graphics_windows_intelx86 1 <------------
einstein_S5R$_6.05_graphics_windows_intelx86 1 <------------
RE: ... A small cosmetic
)
Yes, the app_info.xml file stored in the zip archive does have Unix style line breaks (the single character Unix newline) as opposed to the two character combination of (carriage return, line feed) which is used in MS-DOS text files. As you note, if you read in the file with Wordpad and immediately "save as", the new file you create has the newlines converted to and now Notepad can happily read the file, showing the correct formatting.
Actually, a very good editor to use instead of Windows Notepad is a freeware program called Notepad2 which I've used for years. It's very simple to use and it has some cool editing features that are lacking in Notepad. One of it's many useful settings is the ability to read in either Windows or Unix text files, automatically showing the proper formatting, and to write out text files with whatever style line ending you need. And it doesn't introduce any stray formatting :-).
Cheers,
Gary.
RE: ... if you read in the
)
Actually, if you "Open with..." Wordpad, and simply click the 'Save' icon (floppy disk symbol), the format conversion is done in one click and you don't have to worry about new file names.
But I might check out Notepad2....
RE: ... If at least one of
)
OK, sounds good. Thanks very much for the update.
I'm sure everybody is looking forward to the time when the full range of Windows apps are performing similarly to their Linux counterparts.
Cheers,
Gary.
RE: I'm sure everybody is
)
:whistles:
Nope, not me. Not at all... ;-)
RE: Well I just got mine
)
Not quite sure what you mean by this statement. You always get around 14 to 18 large data files whenever you set up a host to crunch E@H tasks. Once you have those data files, you can potentially get quite a large number of tasks over quite a long period that all depend on the same set of data files. You get exactly the same set of data files irrespective of the version of the science app you will be using.
Each "task" that is sent to you is actually a set of parameters for the science app to use in processing the data in the large files that were previously sent to you. While you continue to be sent tasks for the same frequency band, you won't normally see changes in the large data files. If the scheduler decides to "step up" to the next frequency band, you will normally see a request to delete 2 of the large data files (now "used up") whilst 2 new data files will be downloaded and added to the remaining pool.
When all the available tasks are allocated for a particular set of large data files, the server will take care of deleting all the "used up" files.
The files I imagine you are trying to describe don't exist for the 6.05 version science app because the 6.05 app is confined only to hosts which support SSE2 (or higher) instructions. The _0, _1, etc, terminology has got nothing to do with data files or tasks or workunits. It relates to versions of the science app which have been purpose built to be able to handle different CPU capabilities, such as no SSE, SSE only, SSE+SSE2, etc. With the standard app (like 6.04) there is a "switcher app" which determines the capabilities of your CPU and then runs the appropriately built version of the science app for your CPU. None of this applies to 6.05 because this new version is only applicable to CPUs that have at least SSE2 instructions.
So the answer to your question is that (for 6.05) you wont be seeing any extra versions of the science app that have _0 or _1 etc tags in their name. I trust you did confirm the capabilities of your CPU before you threw version 6.05 into the mix? :-).
Cheers,
Gary.
RE: My initial guess is
)
With ten returned results from this Q6600 in hand, I'll update these estimates.
The mean CPU time of the ten 6.05 results is 25066 seconds, compared to 30248 seconds for a reference sample of twenty-seven results on 6.04 from the same small range of sequence numbers in very closely similar frequencies.
So this update is within Brian's estimate range, 21% productivity improvement, or for those who prefer the execution ratio, 83% as long to finish a result.
I'll update the gif pointed to by my message 89807, and add to this message similar gifs for two other hosts:
Stoll3 is an E6600 Duo running a very similar configuration to Stoll4, my Q6600. However clearly something has disrupted the consistency of its results in the past-possibly my wife's Solitaire game.
Toshiba1 is a laptop which also has a Conroe-class processor, a U7700 running 1.33 GHz, but restricted for BOINC to one cpu.
Bottom line--on this set of Conroe-class Windows XP SP3 hosts 6.05 is a considerable improvement on the Windows 6.04 ap in performance, but not close to the standard distribution Linux ap. More importantly, I've not seen any obvious bad behaviors yet. As I happened to be in the lucky side of the quorum distribution lottery, I've already got validation for all six results from Stoll3 (4 pure shown here, 2 mid-course changed from 6.04), and eleven pure results from Stoll4. Validation on Toshiba1 will have to wait for better luck on the quorum partner front.