std::chrono advertises that it can report results down to the nanosecond level. On a typical x86_64 Linux or Windows machine, how accurate would one expect this to be? What would be the error bars for a measurement of 10 ns, 10 µs, 10 ms, and 10 s, for example?
3 Answers
It's most likely hardware and OS dependent. For example when I ask Windows what the clock frequency is using QueryPerformanceFrequency() I get 3903987, which if you take the inverse of that you get a clock period or resolution of about 256 nanoseconds. This is the value that that my operating system reports.
With std::chrono according to the docs the minimum representable duration is high_resolution_clock::period::num / high_resolution_clock::period::den.
The num and den are numerator and denominator. std::chrono::high_resolution_clock tells me the numerator is 1, and the denominator is 1 billion, supposedly corresponding to 1 nanosecond:
std::cout << (double)std::chrono::high_resolution_clock::period::num /
std::chrono::high_resolution_clock::period::den; // Results in a nanosecond.
So according to the std::chrono I have one nanosecond resolution but I don't believe it because the native OS system call is more likely to be reporting the more accurate frequency/period.
The accuracy will depend upon the application and how this application interacts with the operating system. I am not familiar with chrono specifically, but there are limitations at a lower level you must account for.
For example, if you timestamp network packets using the CPU, the measurement accuracy is very noisy. Even though the precision of the time measurement may be 1 nanosecond, the context switch time for the interrupt corresponding to the packet arrival may be ~1 microsecond. You can accurately measure when your application processes the packet, but not what time the packet arrived.
Short answer: Not accurate in microseconds and below.##
Long answer: I was interested to know about how much my two dp program takes time to execute. So I used the chrono lib but when I ran it it says 0 microseconds. so technically I was unable to compare. I can't increase array size because it will not be possible to extend it to 1e8. So I wrote a sort program to test it and ran it for 100 and the following is the result: enter image description here
It is clearly visible that it is not consistent for same input so I would recommend not to use for higher precision.
chronoare you asking about? - HolyBlackCatperiod()) and accuracy. For instance (a purly hypothetical example, not necessary tied to C++) a clock with nanoseconds resolution could have 0.5 nanoseconds accuracy or 3 nanoseconds resolution or 500 nanoseconds accuracy. The question is about accuracy. - bolovperiodis wrong.periodgives you the resolution of the clock, but it doesn't give you the accuracy of the clock. Very different concepts.steady_clockis required to yield nanosecond-resolution, but there's no requirement that it tick upwards by increments of exactly 1 nanosecond per nanosecond; usually, it ticks upwards by significantly larger intervals. - Xirema