Boost logo

Boost :

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
> 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.

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at