C++ <chrono> header's high_resolution_clock does not have high resolution - by Petter S

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


43
0
Sign in
to vote
ID 719443 Comments
Status Closed Workarounds
Type Bug Repros 9
Opened 1/19/2012 2:47:52 PM
Access Restriction Public
Moderator Decision Sent to Engineering Team for consideration

Description

The C++ chrono header contains a class high_resolution_clock which should be an interface to the system clock with the highest resolution. However, the smallest tick of high_resolution_clock seems to be several million nanoseconds.

The resolution with QueryPerformanceCounter is several orders of magnitude finer.

See details for example code and output.
Sign in to post a comment.
Posted by Petter S on 5/3/2015 at 2:05 AM
Thanks, it works nicely in 2015 RC. (on my machine, I get 294 ns)
Posted by Microsoft on 3/17/2014 at 4:46 PM
Hi,

Thanks for reporting this bug. We've fixed it, and the fix will be available in the next major version of VC (i.e. after 2013).

high_resolution_clock and steady_clock are now synonyms powered by QueryPerformanceCounter(), converted to nanoseconds. Although the conversion introduces overhead, testing on my machine indicates that a program doing nothing but hammering high_resolution_clock can get 6 or 7 calls in before the QPC tick changes, so I believe that the overhead is not problematic.

Stephan T. Lavavej
Senior Developer - Visual C++ Libraries
stl@microsoft.com
Posted by Microsoft on 12/13/2013 at 1:52 PM
This is active and assigned to me, despite its appearance on Connect. I didn't have time to fix this in 2013 RTM (we had barely enough time to overhaul the STL for variadic templates), but I hope to be able to fix this for the next major version. Note that all of the clocks need to be reimplemented, as tracked by several active bugs.

Stephan T. Lavavej
Senior Developer - Visual C++ Libraries
stl@microsoft.com
Posted by Petter S on 11/18/2013 at 4:48 AM
Any progress on this? I reported this for Visual Studio 2010 and now we are using 2013.
Posted by Danil Ilinykh on 11/13/2013 at 4:28 AM
Still not fixed in VS 2013!
Posted by chris_lux on 8/12/2013 at 12:46 AM
Will this be addressed in VC12 RTM?
Posted by Petter S on 7/2/2013 at 10:28 AM
This issue persists in Visual Studio 2013 Preview.
Posted by lednakashim on 5/27/2013 at 12:49 PM
This issue came up at http://stackoverflow.com/questions/16353812/how-to-control-thread-lifetime-using-c11-atomics/16353970#16353970
Posted by Microsoft on 2/21/2013 at 1:48 PM
Hi,

Thanks for reporting this bug. I wanted to let you know what's happening with it. I'm still keeping track of it, but it's been resolved as "Deferred" because we may not have time to fix it in VC12. (Note: VC8 = VS 2005, VC9 = VS 2008, VC10 = VS 2010, VC11 = VS 2012.)

Note: Connect doesn't notify me about comments. If you have any further questions, please E-mail me.

Stephan T. Lavavej
Senior Developer - Visual C++ Libraries
stl@microsoft.com
Posted by Microsoft on 6/18/2012 at 2:38 PM
Hi,

Thanks for reporting this bug. I'm Microsoft's maintainer of the STL, and I wanted to let you know that while this bug remains active in our database, it won't be fixed in VC11 RTM (VS 2012 RTM). All bugs are important to us, but some are more severe than others and rise to the top of our priority queue.

I'm copying-and-pasting this response across all of the STL's active Connect bugs, but the following terse comments apply specifically to your bug:

* I agree that we should be using QPC, and that this is a relatively serious issue. We were simply under significant time pressure (notably, fixing threads/futures/atomics bugs) and this didn't quite meet the bar.

I can't promise when we'll be able to resolve this bug, but we hope to do so as soon as possible (and I'll send another response when that happens) - our first opportunity will be the "out of band" release between VC11 and VC12 that Herb Sutter announced at the GoingNative 2012 conference.

Note: Connect doesn't notify me about comments. If you have any further questions, please E-mail me.

Stephan T. Lavavej
Senior Developer - Visual C++ Libraries
stl@microsoft.com
Posted by Petter S on 4/22/2012 at 3:45 PM
Andrey, you are correct! I got it to work now. Boost 1.47, 64 bit.

     boost::chrono::high_resolution_clock::time_point t3 = boost::chrono::high_resolution_clock::now();
     boost::chrono::high_resolution_clock::time_point t4 = boost::chrono::high_resolution_clock::now();
     while (t3==t4 ) {
        t4 = boost::chrono::high_resolution_clock::now();
     }
     boost::chrono::nanoseconds ns = t4 - t3;

This gave me 410 ns. Not great, but vastly better that the <chrono> header.
Posted by Andrey Bataev on 3/31/2012 at 4:03 AM
Actually boost::chrono uses QueryPerformanceCounter in steady_clock/high_resolution_clock.
Posted by Petter S on 1/20/2012 at 2:59 AM
Let me add that the high_resolution_clock really fills a need among C++ developers of cross-platform code. For example, the Boost library does not provide a timer which have high resolution on Windows.
Posted by MS-Moderator07 [Feedback Moderator] on 1/19/2012 at 9:46 PM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by MS-Moderator01 on 1/19/2012 at 5:47 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)