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