Re: [boost] [chrono] steady_clock efficiency - coherency

Subject: Re: [boost] [chrono] steady_clock efficiency - coherency
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-11-29 17:09:27

Le 29/11/11 09:39, Vicente J. Botet Escriba a écrit :
> Le 29/11/11 04:22, Kenneth Porter a écrit :
>
>> How hard would it be
>> to have now() return a time_point that stores the raw tick value and 
>> only
>> converts it to nanoseconds when a calculation in real units is required?
> Ummm, we can store whatever we want in 
> steady_clock::time_point::duration::rep, but duration::period must be 
> know at compile-time and in Windows this is a run-time information.
> So no,  we cannot store the result of the performances counter and 
> convert it when requiered without making it special case that would 
> break all the chrono architecture.
>>
>> (Comparison to another time_point could still be done in performance
>> counter ticks, saving the multiply.) Is it worth the extra complexity to
>> demand-convert ticks to nanoseconds?
> I see the advantage, I would like to considering it if the 
> performances results are really catastrofic to you.
>
Hi again,

I've been thinking about the cost induced by the run-time getting of the 
period for steady_clock and other clocks.

If I'm not wrong, the fact this period (the processor frequency) can 
change at run-time have as consequence that the measured time could be 
not monotonic neither steady nor exact. Maybe others with more knowledge 
could confirm my suspicion, or the contrary, explain why this is not a 
real problem.

When using these clocks to measure performances, it is clear that what 
we want to measure is the number of ticks, independently of the 
processor frequency change. In addition, as you suggest, the conversion 
to a time_point or a duration could be delayed until the unit is needed. 
Unfortunately the duration class could not be used for this purpose. 
Maybe Boost could have a run-time duration class that stores the number 
of ticks and that is able to make conversions to duration using a 
discrete sample of the period at the time of the conversion.

In this way we could expect that the time spent while doing performance 
measures could maybe divided by 2.

Waiting for some comments from the Boost community,
Vicente

P.S. Beman has added a new version of his Boost.Timer library, that 
maybe it could help you.

Best,
Vicente