Le 28/09/11 13:29, Vicente J. Botet Escriba a écrit :
Le 28/09/11 13:12, Stewart, Robert a écrit :
Vicente J. Botet Escriba wrote:
Le 27/09/11 17:42, Stewart, Robert a écrit :
- There's no information on Boost.Timers overhead relative to timing the target code.
Are you asking for the overhead of the time computations or the reporting? The former.
I will add some performance tests in Boost.Chrono to measure the time spent by the now functions and the difference between two time_points for each one of the clocks, so we can be fixed.
Hi, I have measured the cost of calling Clock::now for some clocks and platforms. All the test are run with variant=release. The measured code stores on a vector the result of Clock::now() 10000000 times. /// for (int i=size-1; i>=0; --i) { vec[i]=Clock::now(); //vec[i]=typename Clock::time_point(typename Clock::time_point::duration(i)); } /// On iMac 3.06 GHz Inter Core i3. clang2.9 system_clock around 44 nanoseconds. steady_clock/high_resolution_clock around 24 nanoseconds. process_real_cpu_clock more than 600 nanoseconds. process_user_cpu_clock more than 1000 nanoseconds. Currently process_real_cpu_clock uses clock() and process_user_cpu_clock uses times(). On MinGw Windows msvc.10 system_clock around 32 nanoseconds. steady_clock/high_resolution_clock more that 2400 nanoseconds. process_real_cpu_clock around 84 nanoseconds. gcc-4.6 system_clock around 38 nanoseconds. steady_clock/high_resolution_clock more that 2500 nanoseconds. process_real_cpu_clock around 110 nanoseconds. Clearly I need to make more measures for the Windows based steady_clock code. The program is available on the trunk under the libs/chrono/perf directory. Could someone run the program on a posix platform? Please let me know if you think there is a better way to make these measures. Best, Vicente