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

Subject: Re: [boost] [Chrono] Proposed library now feature complete
From: Michael Marcin (mike.marcin_at_[hidden])
Date: 2008-11-19 13:42:23

Beman Dawes wrote:
> The Chrono library in the sandbox is now more-or-less feature complete. 
> In addition to the C++0x features, timers have been added to replace the 
> old Boost.Timer library which will become deprecated.
> 
> The feature list includes:
> 
>    *  The C++0x Standard Library's time utilities, including:
>          o Class template duration
>          o Class template time_point
>          o Clocks:
>                + |system_clock|
>                + |monotonic_clock|
>                + |high_resolution_clock|
>                      * Class template |timer|, with typedefs:
>          o |system_timer|
>          o |monotonic_timer|
>          o |high_resolution_timer|
>                * Process clocks and timers:
>          o |process_clock|, capturing real, user-CPU, and system-CPU times.
>          o |process_timer|, capturing elapsed real, user-CPU, and
>            system-CPU times.
>          o |run_timer|, convenient reporting of |process_timer| results.
>                *  The C++0x Standard Library's compile-time rational 
> arithmetic.
> 
> See http://svn.boost.org/svn/boost/sandbox/chrono
> 
> The implementation is now working and lightly tested on Windows with 
> VC++ 9.0 SP1 and Intel ia32 11.0 compilers, and on Ubuntu Linux with GCC 
> 4.2.4 compiler.
> 
> There is a bit more documentation, but it is still needs much work.
> 
> Comments are welcome.
> 

Shouldn't the implementation use boost::throw_exception rather than throw?

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.

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.

In the past I have chosen to use timeGetTime with timeBeginPeriod(1) for 
high resolution timers to avoid these issues.

-- 
Michael Marcin