From: Yuriy Koblents-Mishke (yurakm_at_[hidden])
Date: 2007-01-31 18:57:02
Dear Mr. Dawes:
First of all, I would like to thank you for the small, but very convenient
class. I used it for timing my CPU-intensive codes. However, while using it
on Windows machines, I encountered a problem not reflected in documentation:
== Summary: ==
Boost Timer measures a conceptually different timing under Windows than
under other operation systems. It is proposed to describe the difference in
For modern versions of Windows the problem can be fixed easily, but with
Windows 95/98/ME it is not so.
== Description ==
Under most of operation systems, Boost Timer measures the CPU time consumed
by a program. The timing does not include CPU cycles used by other programs
running on the same computer, nor the time when the program is waiting for
Under Windows, Boost Timer measures instead the whole wall-clock time
elapsed. If other resource-hogging programs like Norton Antivirus, Norton
Speed Disk defragmentor, or Skype are running simultaneously with a timed
program, the timer will reflect it. If you are timing five copies of the
same CPU-bound program, Boost Timer reports that the program became five
times slower. If the timed program is waiting for an user input, the timer
reports how long coffee break the user took.
All of this makes Boost Timer, well, not very suitable for timing of CPU
bound codes running under Windows. Even for a rough timing.
== The reason ==
The underlying problem is in std::clock(). Under Windows, the function does
not measure the amount of CPU time used by a process. It measures instead
the "wall clock" time elapsed since the program started:
see also discussion here:
The Microsoft documentation shows that it is true for all current and recent
desktop versions of Windows, starting from year 1995. To my recollection, it
was true for MS DOS as well. Hardly an ANSI behavior, but it is so.
== Possible solutions ==
1. Taking in account how many computers are running Windows, I would suggest
to describe the difference in Boost Timer documentation. Currently the
documentation discusses a relatively minor problem with low resolution of
Boost Timer under Windows, but does not mention the much bigger issue.
2. It is more debatable is if it makes sense to fix the class.
2.1. Boost Timer was around for so many years already, that it probably
makes sense to retain its old behavior for compatibility - like Microsoft
did with clock() for compatibility with DOS. Personally, I would implement
the fixes as a separate class cpu_timer.
2.2. As it was discussed in the Rationale section of documentation,
different versions of Windows would require different fixes:
On all modern desktop and server versions of MS Windows, starting from NT
ver. 3.51 and including all versions of Windows 2000, Windows XP, Windows
Server 2003, and Windows Vista the right behavior can be implemented using
function GetThreadTimes described in Microsoft documentation:
Windows CE, strating from versions 3.0 or even 2.12, also supports this
function, but vendors can remove it from vendor-specific builds:
For Intel Pentium 4 processors running in hyper-threading mode the solution
will give distorted result, but it is probably unavoidable. See an useful
discussion on the Microsoft forum:
The solution is completely incompatible with Windows 95 / 98 / ME, because
the OS do not support the GetThreadTimes function. Is there is still a need
to support these quaint versions of Windows in the year 2007?
== Additional question ==
You mentioned in the documentation a rejected Win32 implementation submitted
by John Maddock. Where can I find it? I would like to compare it to my
timing codes for Windows.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk