<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 [ I think it spent a shade under 3 hours for me to finish that ~35%  ...but my weekly virus scan did start so I might represent a smaller proportion of that ~46k seconds]

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

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