Performance guarantees for now() call of standard chrono clocks?

Question

Are there any performance guarantees in the standard required for the implement of the now() static functions of each clock in std::chrono?

In n3337 I read that ( 20.11.3 Clock requirements [time.clock.req] ):

3 [ Note: The relative diﬀerence in durations between those reported by a given clock and the SI deﬁnition is a measure of the quality of implementation. — end note ]

Does this mean that it is totally implementation-dependent? Or did I miss something?

This isn't an answer to your question, but you might be interested in the clock shown in the update to this answer: http://stackoverflow.com/a/5524138/576911 which uses the rdtsc assembly instruction on x86. — Howard Hinnant, Sep 13 '12 at 17:37
@HowardHinnant Not portable but interesting and valuable information! Thanks! :) — Klaim, Sep 13 '12 at 17:50
@HowardHinnant: You probably don't want to use RdTsc for anything that depends on the timing. [MSDN lists a lot of reasons](http://msdn.microsoft.com/en-us/library/windows/desktop/ee417693.aspx), including this: *"Multiprocessor and dual-core systems do not guarantee synchronization of their cycle counters between cores. [...] This generally results in glitches or in potential crashes as the thread jumps between the processors and gets timing values that result in large deltas, negative deltas, or halted timing."* — user541686, Sep 13 '12 at 20:50
Yes, the C++ standard is not going to guarantee how quickly a device driver delivers the clock reading to your app. — Hans Passant, Sep 13 '12 at 23:11
@HansPassant The standard could have guarantee that in worse case some work would be done by the library code to provide a value with a specific minimal complexity. Right? Or is it impossible in this case? — Klaim, Sep 13 '12 at 23:21
@Klaim: What do you mean? A function call such as this is considered a single operation, O(1). — GManNickG, Sep 28 '12 at 21:25
@Klaim: Not that I know of, it's pretty implicit everywhere and the reason is practical: we give operations on things like `std::set` complexity requirements because as computer scientists we know the operations could be implemented as any one of a slew of algorithms, and we want to make guarantees about the overall course of action. Getting a time stamp is likely a simple series of steps: no fundamental loops, no fundamental branches. Could it have loops and branches? Sure, but unlike sorting a range, there is no "standard" complexity for such an operation, so we say "do whatever you need". — GManNickG, Sep 28 '12 at 23:46
@GManNickG I think that's the start of an answer you could make? It's not precise requirements (like if it is allowed to be very slow) but that's a start. What i asked was just if there is official requirements. — Klaim, Sep 29 '12 at 00:40
@Klaim: Eh, I don't find it factual enough to become an answer, it's just me reasoning why no requires on time are given for such operations. I think the existing answer is the same, just upvote my comment and that should make this relatively explained. — GManNickG, Sep 29 '12 at 17:23

score 4 · Answer 1 · answered Sep 13 '12 at 17:15

The speed, accuracy, resolution, etc., of the standard clocks are all totally implementation dependent. There are no requirements for any of these aspects of the clocks' performance.

I imagine most any implementation will offer pretty much the best speed and accuracy available from the hardware. On the other hand resolution seems to vary between implementations, with some providing nanoseconds and others providing considerably lower resolution.

Performance guarantees for now() call of standard chrono clocks?

1 Answers1