Seti@Home optimized science apps and information
Optimized Seti@Home apps => Windows => Topic started by: Crunch3r on 02 Sep 2007, 03:00:06 pm
-
Howdy,
there are new apps ready for download both Windows x32 and x64 incl. GFX enabled ones, ALL are new.
You can see there's been a little change in the name tag as well, 2.4v ---> 2.4V is the new one .
There will be a credit multiplier shown in the log file (stderr.txt).
Those apps are compatible with a soon to be released 5.28 stock application that reads the credit multiplier from the workunit header.
DOWNLOAD ---> http://calbe.dw70.de/seti.html
EDIT
Make sure you have a look at the app_info.xml first ! There might by typos in there. So to make sure all will work, have a look for yourself ;)
HTH
Crunch3r
-
I think the app info is incorrect on the AMD SSE2 version, it reads filename "sse" not "sse2". also the amd version executable reads intel em64t when you mouse over it and file does not mention amd after its unzipped.
Just an observation
Thank you for all your hard work Simon and Crunch3r
I appreciate it greatly, as do others.
Mark
-
I think the app info is incorrect on the AMD SSE2 version, it reads filename "sse" not "sse2". also the amd version executable reads intel em64t when you mouse over it and file does not mention amd after its unzipped.
Just an observation
Thank you for all your hard work Simon and Crunch3r
I appreciate it greatly, as do others.
Mark
Thanks. I did fix that file name issue. (that's what happens when you compile apps all day long :P )
About the "Intel EM64T" you don't have to worry about that one. The apps are based on the x64 source tree. That's all it says.
-
Note....
There is a very small bug in the app_info.xml files which causes a 'unparsed line' error that is listed in the Boinc startup messages. It is caused by an extra blank line in the file just before the very last line. It does not cause any problems. You can ignore the error in Boinc, everything works fine. Or if you are so inclined, you can edit the blank line out of the app_info.xml file.
-
Where one can get some info about "GFX" version?
Is it mean it use GPU for part of work? What video cards are supported if any?
wbr
-
GFX means that it has the visual effects turned on.
No use of the GPU whatsoever.
-
Ah... pity ;) ;D
-
Hi,
unfortunately, the KWSN_2.4V_SSE_MB.exe crashes immediately after the start, see http://setiathome.berkeley.edu/forum_thread.php?id=42098
Regards,
Carsten
-
I know, i fixed that one 2 hours ago. Please download it gain. The zip file should be dated 03.09.07 - 16:02 . ;)
-
The user who had first reported the crash of the SSE app has downloaded the new one and posted that it started OK.
-
The user who had first reported the crash of the SSE app has downloaded the new one and posted that it started OK.
Thanks. I did test that one on my old SMP PIII 500MHz. There was and issue in regard to the choosen chirping routine.
However if the app does not crash in the first minute when i does it's optimial function selection, it will work and validate....
;)
-
Could anyone list 5.28 over 5.27 improvements, please?
-
Could anyone list 5.28 over 5.27 improvements, please?
it's faster and compatible with 5.28.
We did bench it on several WUs on different CPUS/OS. That's the major difference between your tests and ours. You only do run a single WU and we did test it with a whole bunch of different WUs both line Feed and MultiBeam(ARs) ;)
-
The user who had first reported the crash of the SSE app has downloaded the new one and posted that it started OK.
Thanks. I did test that one on my old SMP PIII 500MHz. There was and issue in regard to the choosen chirping routine.
However if the app does not crash in the first minute when i does it's optimial function selection, it will work and validate....
;)
A second user also reported that the new compile started OK, and a WU in progress that completed with the new app validated, so methinks we're in the clear on that one.
-
Great news! :)
BTW, could you please point out test WU that best suitable for speed comparision?
Sure whole bunch gives most precise picture but maybe some faster approach is valuable for comparision of different systems?
-
Great news! :)
BTW, could you please point out test WU that best suitable for speed comparision?
Sure whole bunch gives most precise picture but maybe some faster approach is valuable for comparision of different systems?
Better ask Joe or Mark about this one ;) this weekend i did compile about 50 versions of the apps so i only provided the apps and msattler and Joe did the speed testing. I only did a quick check if the apps are working :P
-
Ok :)
Hope they post some info about testbench used here. Wonna get comparable results on my systems too ;)
Some database with test times on different app builds/OSes/ CPUs will be useful IMHO :)
-
Can someone shed some light on the diferences of the three x64 versions please? Or do these three versions correspond with what type of cpu you might have? i.e sse2, sse3 and ssse3 capable cpu's.
I have a Core 2 Duo E6700 @ 3.2ghz (on a P5B Deluxe) which has all three of these extensions, but Im not sure which extension version would run the best. lol
Any help would be appreciated.
And thanks crunch3r for the hard work,
SkOrPn
-
According my own tests SSSE3 64bit under 64-bit OS is the best one for such CPU
So right now probably KWSN_2.4V_SSSE3_MB.exe is the leader :) (from 2.4V_Windows_x64_SSSE3 archive)
-
According my own tests SSSE3 64bit under 64-bit OS is the best one for such CPU
So right now probably KWSN_2.4V_SSSE3_MB.exe is the leader :) (from 2.4V_Windows_x64_SSSE3 archive)
That's what i'm telling people all day long :P However... i do see a possibility to gain another 10 to max 15% in performance... but ONLY for the 64 bit app.
Anyhow, we need to get a common base (2.4V changes) for ALL apps. That' Linux,Windows,UNIX before we can start figuring out how to get some more performance...
-
But for AMD 64 leader is SSE2 32-bit version under 64-bit OS it seems.
Is it because worse Intel compiler optimization for Athlons or something wrong with SSE2 64-bit AMD realization? Just curious...
-
Ok :)
Hope they post some info about testbench used here. Wonna get comparable results on my systems too ;)
Some database with test times on different app builds/OSes/ CPUs will be useful IMHO :)
The testbench I used was the 1.43 knabench available in the downloads 'test and benchmark tools' section.
The test WUs used are attached below. For a short test, just run the 6 FMXXXX wus.. For a longer, more accurate test, use the MBXXXX wus, but they will take much time to run, closer to a full lenght Seti wu.
And I substiuted the 2.2b app (use the one that matches your cpu) for the reference app rather than the old 5.15 that is in the test package.
You had also asked earlier about the best wu to use for comparing apps and platforms. That is the problem, there is no such wu. Different AR wus crunch differently with different apps, some are faster on one than another. So the only way you can test is by running a range of wus and see which app does better overall.
And as far as the result database, Simon has mentioned working on such a thing on the home page of this site. Hopefully he has the time soon to continue work on that project.
[attachment deleted by admin]
[attachment deleted by admin]
-
I use 1.43 knabench too, will run with your WUs now :)
Thank you!
P.S. this test loads only 1 core. As I see from your test file you run it on quad. Did you manage all cores loading with app binding to core (some CPU affinity) ?
imagecfg.exe from test bench doesnt work for me (is it only for NT4 ?)...
-
I use 1.43 knabench too, will run with your WUs now :)
Thank you!
P.S. this test loads only 1 core. As I see from your test file you run it on quad. Did you manage all cores loading with app binding to core (some CPU affinity) ?
imagecfg.exe from test bench doesnt work for me (is it only for NT4 ?)...
No, the testbench only runs a single instance of the test app at a time on one core.. My quad is x64 and is my fastest rig, that's why I run the tests there, because I can test 32 bit and 64 bit apps.
-
According my own tests SSSE3 64bit under 64-bit OS is the best one for such CPU
So right now probably KWSN_2.4V_SSSE3_MB.exe is the leader :) (from 2.4V_Windows_x64_SSSE3 archive)
Thanks for the reply, thankfully that is the version I am running. I used the version with graphics "2.4V_Windows_x64_SSSE3_GFX" but when the screen saver starts I get a blank screen "no graphics"... Wonder if there was something else I was sappose to do to get the nice seti 3D screen saver?
Thanks again for your reply.
-
2 msattler
Yes, this testbench uses only 1 core. My question is : is any test-bench exist to correctly test full-cores-load run times?
AFAIK conroe has common L2 cache for cores so real situation for app when it runs in parrallel on all available cores quite different from single core run.
It's interesting to compare full-load run-times on Core2 Duo/Quadro with Athlon 64 X2 version IMHO.
2 SkOrPn I don't use any graphic or screensaver so cant give any help/comments on your situation, sorry.
-
Yes, this testbench uses only 1 core. My question is : is any test-bench exist to correctly test full-cores-load run times?
AFAIK conroe has common L2 cache for cores so real situation for app when it runs in parrallel on all available cores quite different from single core run.
It's interesting to compare full-load run-times on Core2 Duo/Quadro with Athlon 64 X2 version IMHO.
Interesting point, but I don't know if it's ever been done. You would have to get each app to run on all four cores at the same time. I have no idea if some versions would react differently to sharing the L2 cache than others, but I think the app that tests the best on a single core would still be the best to use running on all four.
-
I know, i fixed that one 2 hours ago.
Many thanks :)
Regards,
Carsten
-
...
is any test-bench exist to correctly test full-cores-load run times?
When running more than one application instance, there is contention for resources. To test all the possible scenarios of different WU angle ranges, offsets of start time, etc. simply would have too many variable effects to permit repeatable tests. That's why the test program shuts down the BOINC service if it's running and does everything on one core.
I don't say a multiple test is impossible, but the amount of time spent testing many scenarios would be more than we can expect volunteer testers to contribute.
Joe
-
...
is any test-bench exist to correctly test full-cores-load run times?
When running more than one application instance, there is contention for resources. To test all the possible scenarios of different WU angle ranges, offsets of start time, etc. simply would have too many variable effects to permit repeatable tests. That's why the test program shuts down the BOINC service if it's running and does everything on one core.
I don't say a multiple test is impossible, but the amount of time spent testing many scenarios would be more than we can expect volunteer testers to contribute.
Joe
If there were a way to test the same app on 2 cores or 4 cores simultaneously, I wouldn't mind knowing if it can be done and trying it..............would it be a hard thing to modify the knabench script to do it, or really just not worth the bother?
-
According my own tests SSSE3 64bit under 64-bit OS is the best one for such CPU
So right now probably KWSN_2.4V_SSSE3_MB.exe is the leader :) (from 2.4V_Windows_x64_SSSE3 archive)
That's what i'm telling people all day long :P However... i do see a possibility to gain another 10 to max 15% in performance... but ONLY for the 64 bit app.
Anyhow, we need to get a common base (2.4V changes) for ALL apps. That' Linux,Windows,UNIX before we can start figuring out how to get some more performance...
So if I have the QX6700 with WinVista Home Basic 64Bit..
The best performance I have with the SSSE3- 32Bit app now?
BTW.
I saw that the opt. app have a lower 'Claimed credit' than the stock app..
This is 'only' sometimes with this special AR?
This are only -0.02, but.. ;)
(The opt. app is from 08/26/2007)
_____________________________________________________
<core_client_version>5.10.13</core_client_version>
<![CDATA[
<stderr_txt>
setiathome_enhanced 5.27 DevC++/MinGW
Work Unit Info:
...............
WU true angle range is : 1.393579
Optimal function choices:
-----------------------------------------------------
name
-----------------------------------------------------
v_BaseLineSmooth (no other)
v_vGetPowerSpectrumUnrolled 0.00013 0.00000
sse1_ChirpData_ak 0.01417 0.00000
v_vTranspose4 0.00449 0.00000
AK SSE folding 0.00083 0.00000
Flopcounter: 5876485106912.311500
Spike count: 1
Pulse count: 0
Triplet count: 2
Gaussian count: 0
</stderr_txt>
]]>
Validate state Initial
Claimed credit 19.4006742531251
_____________________________________________________
_____________________________________________________
<core_client_version>5.10.13</core_client_version>
<![CDATA[
<stderr_txt>
Optimized SETI@Home Enhanced application
Optimizers: Ben Herndon, Josef Segur, Alex Kan, Simon Zadra
Version: Windows SSSE3 32-bit based on S@H V5.15 'Noo? No - Ni!'
Revision: R-2.4v|xT|FFT:IPP_SSSE3|Ben-Joe
CPUID: Intel(R) Core(TM)2 Quad CPU @ 2.66GHz
Speed: 4 x 3143 MHz
Cache: L1=64K L2=4096K
Features: MMX SSE SSE2 SSE3 SSSE3
Work Unit Info
True angle range: 1.393579
Spikes Pulses Triplets Gaussians Flops
1 0 2 0 5875824229395
</stderr_txt>
]]>
Validate state Initial
Claimed credit 19.3820590900193
_____________________________________________________
-
...
BTW.
I saw that the opt. app have a lower 'Claimed credit' than the stock app..
This is 'only' sometimes with this special AR?
This are only -0.02, but.. ;)
Some of the alternative routines which are checked for performance just after startup have flop counting embedded. The stock app uses a different and longer lasting routine to test for which routines are optimal, so accrues more flops due to testing.
If the angle range were within the about 0.226 to 1.12 limits for Gaussian fitting, then two WUs with the same angle range but different data could have larger credit differences because each Gaussian test starts with a precheck which can get out quickly if the data has too little range to possibly find a Gaussian. When it takes that early exit there are fewer flops counted for the test.
Joe
-
So if I have the QX6700 with WinVista Home Basic 64Bit..
The best performance I have with the SSSE3- 32Bit app now?
Under Win2003 it's 64-bit one (on Core2 class CPU). Probably the same for 64-bit Vista...
-
...
If there were a way to test the same app on 2 cores or 4 cores simultaneously, I wouldn't mind knowing if it can be done and trying it..............would it be a hard thing to modify the knabench script to do it, or really just not worth the bother?
It might be possible to modify knabench that way, but certainly difficult.
There is a way to do realistic testing, though. It requires a cache of work, but none which might cause going into EDF during the test.
1. Turn off Network activity in BOINC, then shut it down.
2. Make another folder, say BOINCTEST.
3. Copy everything from the BOINC folder and its subdirectories to BOINCTEST.
4. Install the application you want to test in the project folder below BOINCTEST.
5. Start a timer and the Boinc Manager in BOINCTEST.
6. Run for say two hours then save all messages from BOINC Manager and shut down. Make a copy of client_state.xml, that and the saved messages are the test results.
7. To test another app, wipe out all the contents of BOINCTEST and go back to step 3.
This should be possible on any platform with minor modifications. I wouldn't recommend comparing more than two apps this way, it does require going through the messages and/or client_state.xml files and checking time differences, contents of stderr reports, etc. But it's about as realistic as testing can be, each test using identical WUs starting at the same points.
Joe
-
Well, this approach assumes to use "normal" full-length WUs. Really realistic one ;) but at least one WU per core should be completed during the test because of not perfectly linear %of work done changing during WU calculation, right? This can take more than 2 hours on lower CPUs :'(
Does CPU time for WUs with the same AR spread widely to not allow statistical approach?
And how CPU time logged on web-page corresponds real time spent on WU (assuming app running 100% of time)? Are any CPU-time corrections performed?
It might be possible to modify knabench that way, but certainly difficult.
All we need is some utility that starts prescribed app in prescribed quantity and set affinity to each child process (optional step? does last BOINC versions do this ?) and wait for all childs exit,t hen exits
such utility then may be used instead of optimized app in knabench, right? This approach will test "worst case" of simultaneous calculation - time for completion of all work on all cores.
-
...
If there were a way to test the same app on 2 cores or 4 cores simultaneously, I wouldn't mind knowing if it can be done and trying it..............would it be a hard thing to modify the knabench script to do it, or really just not worth the bother?
It might be possible to modify knabench that way, but certainly difficult.
There is a way to do realistic testing, though. It requires a cache of work, but none which might cause going into EDF during the test.
1. Turn off Network activity in BOINC, then shut it down.
2. Make another folder, say BOINCTEST.
3. Copy everything from the BOINC folder and its subdirectories to BOINCTEST.
4. Install the application you want to test in the project folder below BOINCTEST.
5. Start a timer and the Boinc Manager in BOINCTEST.
6. Run for say two hours then save all messages from BOINC Manager and shut down. Make a copy of client_state.xml, that and the saved messages are the test results.
7. To test another app, wipe out all the contents of BOINCTEST and go back to step 3.
This should be possible on any platform with minor modifications. I wouldn't recommend comparing more than two apps this way, it does require going through the messages and/or client_state.xml files and checking time differences, contents of stderr reports, etc. But it's about as realistic as testing can be, each test using identical WUs starting at the same points.
Joe
Thanks Joe! You've given me some food for thought there. As you mentioned earlier, may be very time consuming to play with, but you've go my curiosity going now. As the holiday is over and I have to go back to work today, it'll have to wait until perhaps this weekend, but I may experiment with your approach.
-
Well, this approach assumes to use "normal" full-length WUs. Really realistic one ;) but at least one WU per core should be completed during the test because of not perfectly linear %of work done changing during WU calculation, right? This can take more than 2 hours on lower CPUs :'(
Although the progress isn't perfectly linear, it is monotonic (never goes backward) and is close enough to linear to remain useful. I don't think the method can provide precise speed comparison in any case, but should clearly indicate which of two apps is faster on whatever mix of work is present. Completing WUs for each core would give result files which could be compared, but my presumption was this sort of extended testing would only be used for apps already known to produce correct results.
Does CPU time for WUs with the same AR spread widely to not allow statistical approach?
Contention can cause something like 30% CPU time differences, the data in WUs with equal angle range probably no more than 2%.
And how CPU time logged on web-page corresponds real time spent on WU (assuming app running 100% of time)? Are any CPU-time corrections performed?
IIRC, BOINC doesn't start the CPU time when it launches the app, rather when the app initiates its BOINC imterface. After that, CPU time accrues as accurately as the OS allows. On my Win2k Pentium-M system, Windows Task Manager shows about 2.5 seconds more CPU time for the current SETI task than BOINC Manager does. Most of that difference is probably delay in the BOINC Manager getting the data from the core client and displaying it.
Joe
-
Well Joe, my thought were somewhere along the lines of cloning the WUs, so that you had 4 copies of the same WU (to test on a quad), so that you could get 4 instances of the same WU to run at the same time.
-
Thank you very much for detailed answer! You right, there is no need in linear percentage to chose faster/slower case in case of all % bigger or all % smaller.
I imagined case in that lets' say WU-1 got 50%, WU-2 got 95% and with second app WU-1 got 52% and WU-2 got 90%. In that case we cant just sum up nonlinear %. But don't know will be such situation in real testing or not (BTW, completion of full WU doesnt help anyway, you right).
Only one refinement - the maximum CPU time for WU is the same that time that logged with result on project web page? Not artifical time correction (some multiplier or so? )
As I remember there was a time that some optimized app adjusted CPU time logged to achive correct credit allocation - from that case my question arose.
-
Well Joe, my thought were somewhere along the lines of cloning the WUs, so that you had 4 copies of the same WU (to test on a quad), so that you could get 4 instances of the same WU to run at the same time.
That's probably possible by naming the cloned WUs with existing queued WU names and suspending other WUs so only those run. It may cause maximum contention, having all 4 cores trying to do exactly the same things at the same time. OTOH, initial contention might get the 4 instances an ideal amount out of phase so they'd perform very well.
Joe
-
...
Only one refinement - the maximum CPU time for WU is the same that time that logged with result on project web page? Not artifical time correction (some multiplier or so? )
As I remember there was a time that some optimized app adjusted CPU time logged to achive correct credit allocation - from that case my question arose.
Trux's optimized BOINC core client "calibration" feature adjusted both reported CPU time and BOINC benchmarks. It was a well-intentioned attempt to correct the logical flaw in the old method of generating credit claims. Our apps certainly don't make any time adjustments, total CPU time for a day of running will be very close to 24 hours times the number of CPUs in the host.
Joe
-
One idea of this is to update Knabench to have a separate Multithread drawer where the temporary files can be created and a specifically chosen or more WUs lie.
A little program is called to se how many threads the cpu can run in parallell and then creates dir cpu1,cpu2,cpu3 and cpu4 for instance..
Then u could create a call procedure to execute multiple apps that calculates each thread and waits for the last one to return, perhaps u even can make a callroutine that executes on X cpu/thread (affinity)..
If this could be acomplished we will soon see which app that is the best compile for use in parallell execution..
This is thoughts and nothing but thoughts.
There is a app called Wprime that u can enter how many threads it is going to start and a Dos windows appear that takes care of this.. http://www.wprime.net ..
Kind Regards Vyper
-
Howdy,
there are new apps ready for download both Windows x32 and x64 incl. GFX enabled ones, ALL are new.
You can see there's been a little change in the name tag as well, 2.4v ---> 2.4V is the new one .
There will be a credit multiplier shown in the log file (stderr.txt).
Those apps are compatible with a soon to be released 5.28 stock application that reads the credit multiplier from the workunit header.
DOWNLOAD ---> http://calbe.dw70.de/seti.html
EDIT
Make sure you have a look at the app_info.xml first ! There might by typos in there. So to make sure all will work, have a look for yourself ;)
HTH
Crunch3r
Are there plans to relese a new automatic installer / test and benchmark tool or should i just download the same app as the 2.2 version currently running and asume this is again the fastest for my setup.
-
Are there plans to relese a new automatic installer / test and benchmark tool or should i just download the same app as the 2.2 version currently running and asume this is again the fastest for my setup.
Installing the 2.4V equivalents to the 2.2B versions you were using is the best approach for now. There may eventually be an automatic install / test, but not soon.
Joe
-
Will give it a try today.
Thanks.
-
The win32 link is broken? -> http://calbe.dw70.de/win32.html
or is it just me?
Live long and BOINC!
-
The win32 link is broken? -> http://calbe.dw70.de/win32.html
or is it just me?
Live long and BOINC!
It is under reconstruction it says at main page at http://calbe.dw70.de/