3

I have suprising observation that steady_clock gives poor 10ms resolution when measuring durations. I compile for windows under cygwin. Is it sad true or am I doing sth wrong?

auto start = std::chrono::steady_clock::now();
/*...*/
auto end = std::chrono::steady_clock::now();
std::cout << std::chrono::duration_cast<std::chrono::microseconds>
                                                   (end - start).count();

Result is 10000,20000 etc.

ardabro
  • 1,907
  • 16
  • 31
  • 2
    You're not doing anything wrong. It's just an example of a poor quality implementation. For whatever reason there's been a pretty consistent problem with timers on Windows. With Visual Studio as well, up through VS 2013 I think, the chrono clocks have thus far been much lower resolution than modern hardware should support. VS's standard library maintainer has said the implementations in VS2015 should be fixed, finally. – bames53 Apr 10 '15 at 00:40

1 Answers1

1

The resolution of std::steady_clock is implementation dependent, and you shouldn't rely on a precise minimum duration. It varies across platforms/compiler implementations.

From http://cppreference.com:

Class std::chrono::steady_clock represents a monotonic clock. The time points of this clock cannot decrease as physical time moves forward. This clock is not related to wall clock time, and is best suitable for measuring intervals.

Related: Difference between std::system_clock and std::steady_clock?

If you don't care about monotonicity (i.e., you don't care if someone changes the wall clock while your program is running), you're probably better off with a std::high_resolution_clock. (the latter is still implementation-dependent)

Community
  • 1
  • 1
vsoftco
  • 55,410
  • 12
  • 139
  • 252
  • I know that it is implementation dependent but for me 10ms is ridiculous on machines with >1Ghz cpu clock. – ardabro Apr 10 '15 at 00:11
  • @ardabro that's because `std::steady_clock` was not made for measuring atomic decays etc, but for measuring the time stamps some persons came in a ticket line or stuff like that. Try `std::high_resolution`, it is probably 3 orders of magnitude better. In the former case, if you change from Winter time to Summer time, you better make sure all of the "arrived-in-line" times are not modified, as otherwise you end up with a huge mess, so you use a `std::steady_clock` :) – vsoftco Apr 10 '15 at 00:12
  • 1
    It's entirely reasonable for `steady_clock` to have a resolution in the hundreds of nanoseconds. libc++ on OS X has this, as does libstdc++ on Linux. I believe even VS2015 will final support a reasonable resolution. – bames53 Apr 10 '15 at 01:00
  • @bames53 agree, that's why I said it is implementation-dependent. I wouldn't use it in a mars-landing system that's worth $USD 2 billion. However, the C++ standard does not require a minimum resolution. One can even have 1s resolution if some crazy compiler writer really wants it. – vsoftco Apr 10 '15 at 01:01
  • @bames53 Unfortunately I don't think a minimum is requited for `std::high_resolution_clock` either. This is reasonable, since C++ is multi-platform multi-harware, and it has to run on any kind of machine one can imagine (except a quantum device :) ). – vsoftco Apr 10 '15 at 01:08
  • 1
    I'm not saying that this implementation is non-conformant; I'm saying it's not a good quality implementation. The hardware can and does support better, and you don't need to be measuring atomic decays or landing a $2 billion mars lander to benefit from timer resolutions better than 10 milliseconds. I also agree it's entirely reasonable for the specification not to require a particular resolution. At the same time implementations should be high quality, using the freedom the spec gives them to be as good as they can be, not the worst quality they can get away with. – bames53 Apr 10 '15 at 01:23
  • @bames53 I understand, but you should probably ask the writers of the compiler. And they will say: *look, I didn't do anything wrong, I complied to the standard because I was too lazy to provide a better implementation* (just kidding though:) ) – vsoftco Apr 10 '15 at 01:25
  • In the past when people complained about one implementation the implementer agreed and [fixed it](https://connect.microsoft.com/VisualStudio/feedback/details/719443/). – bames53 Apr 10 '15 at 01:31
  • @bames53 well... good luck with that. Unfortunately, VS2013 is one of the main compilers on the market that still has relatively poor support for C++11. But the whole idea is that, disregarding this question, they are not at fault. You should just not rely on some minimum duration and that's the end of story. If you want something super-precise, then relying on standard C++ library implementation is not the way to go, and I tell you this from personal experience. – vsoftco Apr 10 '15 at 01:35
  • @bames53 the OP's question is similar (in flavour) to something I've also asked: http://stackoverflow.com/questions/28390843/how-to-find-the-true-entropy-of-stdrandom-device And I guess the end result is that you shouldn't bet your money on something like minimum duration/true randomness or similar stuff. – vsoftco Apr 10 '15 at 01:42
  • You have the wrong attitude about C++ quality of implementation. Did you know know that `fopen` or `fstream` doesn't have to actually support opening files? Would you say that complaints about a C++ implementation where `fopen` cannot open any files are legitimate? Would you say that the implementer 'is not at fault' for providing such an `fopen`? Would you say that no-one should ever use `fopen` if they need to open files, just because implementations are not required to succeed? What I would do is tell them to fix their implementation and then go use an implementation that works. – bames53 Apr 10 '15 at 01:50
  • @bames53 fair enough, C++ standard uses an "abstract machine" when defining the standard, but the question of "why X didn't implement f() with Y digits of precision" is not something one can truly argue on. Again my guess is that it was easier, and no one was really forced to do a better job. – vsoftco Apr 10 '15 at 01:52
  • You can file bugs or contribute code to an open source implementation. Seriously, implementers want to provide good implementations, not get away with as whatever crap they can. It's simply that they have limited resources and have to decide exactly how to spend them; they can't just do everything they'd like to do. – bames53 Apr 10 '15 at 02:03
  • Funny: bit older gcc on debian (4.9.1 vs 4.9.2 on windows) gives nanosecond resolution! And it seems to be reasonable - lower positions "flow" from test to test. – ardabro Apr 10 '15 at 04:52
  • 1
    as far as I can tell, the answer to the actual question is: "Yes, mingw has a low-quality implementation of steady_clock". This "answer" isn't answering the question. The question is clearly not asking whether this behaviour is standars conforming or not. – Arvid Jul 04 '19 at 09:28