Re: [boost] [Chrono] Proposed library now feature complete

Subject: Re: [boost] [Chrono] Proposed library now feature complete
From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-11-21 10:07:21

On Wed, Nov 19, 2008 at 1:42 PM, Michael Marcin <mike.marcin_at_[hidden]> 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