Re: [boost] [chrono] steady_clock efficiency

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

Le 29/11/11 04:22, Kenneth Porter a écrit :
> I expect most people will use boost::chrono::steady_clock to measure
> performance.
I guess that also.
> I've been considering switching from my raw calls to the
> Windows peformance counter APIs to the steady_clock. I'm a little worried
> about the overhead of what should be a non-intrusive facility.
Glad to hear you are considering it. Have you any measures that let you 
think there is a serious overhead? How do you use the ::now() function 
to make your performance measures?
> In examing the source, I see that steady_clock::now() reads the performance
> counter and then multiplies it by the reciprocal of the counter's frequency
> (acquired on first use of the clock) to return the time in nanoseconds. How
> expensive is this 64 bit multiply on a 32 bit system?
I have added recently a performance test in 
https://svn.boost.org/svn/boost/branches/release/libs/chrono/perf/store_now_in_vector.cpp. 
I have no access to a windows platform now, but if you could run it in 
your system?  For a Mac-OS

I get for 100000 the following figures

debug

system_clock  107995476 nanoseconds
changes: 137173
steady_clock  27631675 nanoseconds
changes: 999999
high_resolution_clock  27683032 nanoseconds
changes: 999999
process_real_cpu_clock  640388694 nanoseconds
changes: 560828
process_user_cpu_clock  1090746878 nanoseconds
changes: 50
process_system_cpu_clock  1083428100 nanoseconds
changes: 62
process_cpu_clock  1093743446 nanoseconds
changes: 238

release

system_clock  44870075 nanoseconds
changes: 46173
steady_clock  23371245 nanoseconds
changes: 999999
high_resolution_clock  23554410 nanoseconds
changes: 999999
process_real_cpu_clock  619828025 nanoseconds
changes: 531914
process_user_cpu_clock  1079721262 nanoseconds
changes: 45
process_system_cpu_clock  1081643605 nanoseconds
changes: 63
process_cpu_clock  1077525848 nanoseconds
changes: 217

That is ~24ns for steady_clock::now().

> 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.

Best,
Vicente