Forum > Windows
Best compiler options
Jason G:
<wu_cpu_time>45502.234375</wu_cpu_time>
I guess that this includes your ~65% time ? seems like a rather long workunit ... or both our computers / apps are really slow :D [ I think it spent a shade under 3 hours for me to finish that ~35% :o...but my weekly virus scan did start so I might represent a smaller proportion of that ~46k seconds]
Raistmer:
:)
Not sure about keeping CPU time along with intermediate results. It seems flops counter is keeped instread. And % of work done. Didnt notice CPU time field in state.sah.
Josef W. Segur:
--- Quote from: Raistmer on 25 Nov 2007, 04:00:31 am ---:)
Not sure about keeping CPU time along with intermediate results. It seems flops counter is keeped instread. And % of work done. Didnt notice CPU time field in state.sah.
--- End quote ---
CPU time is kept in the init_data.xml file. When working with BOINC that's in the slot directory so you get a fresh copy when starting a new WU. When the app shuts down it adds its current internal elapsed time to whatever was there before. So stopping a standalone run and deleting state.sah to restart at the beginning just keeps adding to the <wu_cpu_time> in init_data.xml.
The internal elapsed time is only updated when checkpointing, so using <wu_cpu_time> as an indicator of speed involves very poor granularity. It's not the same CPU time which is reported to BOINC.
Joe
Raistmer:
--- Quote from: Josef W. Segur on 25 Nov 2007, 01:29:48 pm --- It's not the same CPU time which is reported to BOINC.
--- End quote ---
But in conjunction of % done field of state.sah? Are they written "atomicaly" at checkpointing? I mean if for example state.sah said 50% done in both cases and init_data.xml shows different times is it that difference that BOINC would show at 50% done moment for that tasks?
Josef W. Segur:
--- Quote from: Josef W. Segur on 25 Nov 2007, 01:29:48 pm --- It's not the same CPU time which is reported to BOINC.
--- End quote ---
--- Quote from: Raistmer on 26 Nov 2007, 11:22:45 am ---But in conjunction of % done field of state.sah? Are they written "atomicaly" at checkpointing? I mean if for example state.sah said 50% done in both cases and init_data.xml shows different times is it that difference that BOINC would show at 50% done moment for that tasks?
--- End quote ---
If you have two separate runs stopped when the <prog> field in state.sah indicates 50% the <wu_cpu_time> in init_data.xml does reflect the time associated with the checkpoint. If the <prog> values are quite close, doing a speed comparison that way should be reliable.
However, the progress calculation is not extremely linear. It's based on approximations of the relative time to do FFTs, chirping, and the various kinds of signal searches. Those approximations were last adjusted before setiathome_enhanced was released to the main project and even then it only produced roughly linear progress. With optimizations applied, a single set of approximations cannot be accurate. Theoretically an adjustment could be applied based on the relative timings of the "standard" routines and the chosen optimized routines, but it would take a fair amount of programming to implement and much testing time to get right.
Because all my hosts are single CPU, my preference has been to adjust the chirp limits in a WU to give a useful full run time, do the standalone testing with very little else running, and use the elapsed wall time in speed comparison. The extremely shortened testWU-1 and similar are definitely a compromise between accuracy and how much time is reasonable to ask of volunteer testers. I'd prefer test WUs with the chirp limits scaled down by a factor of 5 at most, TestWU-1 was scaled by 20 relative to the old 20 and 50 limits and that's about 30 or 40 relative to MB WUs.
For multi-CPU systems I think what would work best is using full run test WUs, but divide the final <wu_cpu_time> from init_data.xml by the <prog> value in the final state.sah to adjust for the partial checkpoint interval at the end.
Joe
Navigation
[0] Message Index
[*] Previous page
Go to full version