How get very precise elapsed time C++
Asked Answered
L

3

7

I'm running my code on Ubuntu, and I need to get the elapsed time about a function on my program. I need a very accurate time, like nano seconds or at least micro seconds.

I read about chrono.h but it uses system time, and I prefer use CPU time.

Is there a way to do that, and have that granularity (nano seconds)?

Lyonnesse answered 18/10, 2016 at 9:57 Comment(9)
https://mcmap.net/q/1061268/-several-questions-about-lt-chrono-gt-header-in-c-11 "If you want CPU time but also want the benefits that <chrono> provides, you should implement a clock type that conforms to the Clock concept outlined in the standard and which provides CPU time, perhaps implemented internally using std::clock()."Hackberry
How about the high-resolution clock?Resht
here is also something on this: #275504Wintery
@GillBates The problem with std::clock is that while it is in the standard, it is not working the same among the major platforms (Windows bases the result of the wall clock). On POSIX systems there are also higher-resolution system-specific clocks.Resht
@JoachimPileborg Indeed, but none of them promise CPU clock time as the OP asks.Hackberry
I don't think this is possible without specialist hardware.Neurocoele
@GillBates Well neither does the clock function in Windows (like I said).Resht
Not even the performance counter in Windows has such a good resolution. 1ms is the best you can do and then you have to fiddle with a global setting to get it.Neurocoele
@JoachimPileborg mhm, Good thing we have std::chrono::I_am_sure_this_clock_runs_on_cpu_time.Hackberry
M
2

The achievable precision of the clock is one of the properties of different hardware / OS that still leak into virtually every language, and, to be honest, having been in the same situation I find building yourself an own abstraction that is good enough in your case is often the only choice.

That being said, I would avoid the STL for high-precision timing. Since it is a library standard with no one true implementation, it has to create an abstraction, which implies one of:

  • use a least common denominator
  • leak hardware/OS details through platform-dependent behavior

In the second case you are essentially back to where you started, if you want to have uniform behavior. If you can afford the possible loss of precision or the deviations of a standard clock, then by all means use it. Clocks are hard and subtle.

If you know your target environment you can choose the appropriate clocks the oldschool way (#ifdef PLATFORM_ID...), e.g. clock_gettime(), QPC), and implement the most precise abstraction you can get. Of course you are limited by the same choice the STL has to make, but by reducing the set of platforms, you can generally improve on the lcd-requirement.

If you need a more theoretical way to convince yourself of this argumentation, you can consider the set of clocks with their maximum precision, and a sequence of accesses to the current time. For clocks advancing uniformly in uniform steps, if two accesses happen faster than the maximum precision of one clock, but slower than the maximum precision of another clock, you are bound to get different behavior. If on the other hand you ensure that two accesses are at least the maximum precision of the slowest clock apart the behavior is the same. Now of course real clocks are not advancing uniformly (clock drift), and also not in unit-steps.

Milliard answered 18/10, 2016 at 11:0 Comment(0)
R
4

std::chrono does have a high_resolution_clock, though please bear in mind that the precision is limited by the processor.

If you want to use functions directory from libc, you can use gettimeofday but as before there is no guarantee that this will be nanosecond accurate. (this is only microsecond accuracy)

Redaredact answered 18/10, 2016 at 10:6 Comment(2)
Also since any time query involves a kernel call, the time lost changing into and out of kernel mode, will probably lose enough nanoseconds to any attempt at nanosecond accuracy moot.Redaredact
+1 high_resolution_clock should be the way to go. But it is not guaranteed to have nanosecond resolution. It should just be the highest resolution clock in the system. If you want to be absolutely sure you'll have to look at your operating systems possibilities of measuring time (e.g. QueryPerformanceFrequency/Counter on Windows)Rubber
M
2

The achievable precision of the clock is one of the properties of different hardware / OS that still leak into virtually every language, and, to be honest, having been in the same situation I find building yourself an own abstraction that is good enough in your case is often the only choice.

That being said, I would avoid the STL for high-precision timing. Since it is a library standard with no one true implementation, it has to create an abstraction, which implies one of:

  • use a least common denominator
  • leak hardware/OS details through platform-dependent behavior

In the second case you are essentially back to where you started, if you want to have uniform behavior. If you can afford the possible loss of precision or the deviations of a standard clock, then by all means use it. Clocks are hard and subtle.

If you know your target environment you can choose the appropriate clocks the oldschool way (#ifdef PLATFORM_ID...), e.g. clock_gettime(), QPC), and implement the most precise abstraction you can get. Of course you are limited by the same choice the STL has to make, but by reducing the set of platforms, you can generally improve on the lcd-requirement.

If you need a more theoretical way to convince yourself of this argumentation, you can consider the set of clocks with their maximum precision, and a sequence of accesses to the current time. For clocks advancing uniformly in uniform steps, if two accesses happen faster than the maximum precision of one clock, but slower than the maximum precision of another clock, you are bound to get different behavior. If on the other hand you ensure that two accesses are at least the maximum precision of the slowest clock apart the behavior is the same. Now of course real clocks are not advancing uniformly (clock drift), and also not in unit-steps.

Milliard answered 18/10, 2016 at 11:0 Comment(0)
R
1

While there is a standards function that should return the CPU time (std::clock) in reality there's no portable way to do this.

On POSIX systems (which Linux is attempting to be) then std::clock should do the right thing though. Just don't expect it to work the same on non-POSIX platforms if you ever want to make your application portable.

The values returned by std::clock are also approximate, and the precision and resolution is system dependent.

Resht answered 18/10, 2016 at 10:8 Comment(1)
on posix systems (which probably applies to Ubuntu) CLOCKS_PER_SEC is 1000000 which means that clock only has microsecond resolution.Redaredact

© 2022 - 2024 — McMap. All rights reserved.