+- +-
Say hello if visiting :) by Gecko
11 Jan 2023, 07:43:05 pm

Seti is down again by Mike
09 Aug 2017, 10:02:44 am

Some considerations regarding OpenCL MultiBeam app tuning from algorithm view by Raistmer
11 Dec 2016, 06:30:56 am

Loading APU to the limit: performance considerations by Mike
05 Nov 2016, 06:49:26 am

Better sleep on Windows - new round by Raistmer
26 Aug 2016, 02:02:31 pm

Author Topic: Best compiler options  (Read 17923 times)

Offline Jason G

  • Construction Fraggle
  • Knight who says 'Ni!'
  • *****
  • Posts: 8980
Re: Best compiler options
« Reply #15 on: 23 Nov 2007, 08:13:24 pm »
<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]
« Last Edit: 23 Nov 2007, 08:17:18 pm by j_groothu »

Offline Raistmer

  • Working Code Wizard
  • Volunteer Developer
  • Knight who says 'Ni!'
  • *****
  • Posts: 14349
Re: Best compiler options
« Reply #16 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.

Offline Josef W. Segur

  • Janitor o' the Board
  • Knight who says 'Ni!'
  • *****
  • Posts: 3112
Re: Best compiler options
« Reply #17 on: 25 Nov 2007, 01:29:48 pm »
:)
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.

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
« Last Edit: 25 Nov 2007, 01:43:55 pm by Josef W. Segur »

Offline Raistmer

  • Working Code Wizard
  • Volunteer Developer
  • Knight who says 'Ni!'
  • *****
  • Posts: 14349
Re: Best compiler options
« Reply #18 on: 26 Nov 2007, 11:22:45 am »
It's not the same CPU time which is reported to BOINC.
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?

Offline Josef W. Segur

  • Janitor o' the Board
  • Knight who says 'Ni!'
  • *****
  • Posts: 3112
Re: Best compiler options
« Reply #19 on: 26 Nov 2007, 02:21:59 pm »
It's not the same CPU time which is reported to BOINC.
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?

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
« Last Edit: 26 Nov 2007, 02:24:37 pm by Josef W. Segur »

 

Welcome, Guest.
Please login or register.
 
 
 
Forgot your password?
Members
Total Members: 97
Latest: ToeBee
New This Month: 0
New This Week: 0
New Today: 0
Stats
Total Posts: 59559
Total Topics: 1672
Most Online Today: 4
Most Online Ever: 983
(20 Jan 2020, 03:17:55 pm)
Users Online
Members: 0
Guests: 110
Total: 110
Powered by EzPortal