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
Le 29/11/11 04:22, Kenneth Porter a écrit : 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_.... 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