On Wed, Nov 19, 2008 at 1:42 PM, Michael Marcin <mike.marcin@gmail.com> wrote:
Shouldn't the implementation use boost::throw_exception rather than throw?
Yes, and originally it did. But there was an issue with Intel 11.0 so for the moment the implementation is just plain throwing. I've stuck a TODO list near the front of chrono.hpp to track issues so they don't get forgotten.
In the past I've seen QueryPerformanceCounter give incorrect results, especially with SpeedStep processors on laptops. This was many years ago and might have been fixed by service packs and drivers.
Yeah, I'm aware that QueryPerformanceCounter is widely considered to be problematical. I'm still in the phase of development where getting the interface/tests/docs complete is more important than the implementation.
Typically you check the results of QPC against GetTickCount to see if the results are reasonable. http://support.microsoft.com/kb/274323
I've also heard of problems with QueryPerformanceCounter in multi-processor systems.
I know some people SetThreadAffinityMask to 1 for the current thread call their QueryPerformance* functions then restore SetThreadAffinityMask. This seems horrible to me because it forces your program to jump to another physical processor if it isn't already on cpu0 but they claim it worked well in practice because they called the timing functions infrequently.
I'm wondering if there are really two separate needs; a high-precision low-overhead timer that may give incorrect results if not used carefully, and an always reliable timer that has more internal overhead and may have lower precision.
In the past I have chosen to use timeGetTime with timeBeginPeriod(1) for high resolution timers to avoid these issues.
I wasn't aware of that API. I'll take a look. Thanks for the comments, --Beman