From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-06-25 21:41:17
Gennaro Prota wrote:
> On Sun, 25 Jun 2006 10:00:46 -0400, Beman Dawes <bdawes_at_[hidden]>
>> After years of procrastination, I've finally put together the CPU timer
>> I've always wanted. It provides wall-clock time, user CPU time, and
>> system CPU time. A time reporter class handles the details of display.
>> Typical output would be:
>> wall 0.50 s, user 0.03 s, system 0.05 s, total cpu 0.08 s, 15.6%
>> The percentage is CPU utilization relative to wall clock.
>> Note that I see a CPU timer as complementary rather than competitive to
>> the high-precision timer component others are working on. I'm all for
>> their effort to continue.
>> My plan is to submit the CPU timer stuff as part of a Boost.System
>> library, which packages small operating system dependent components
>> together for convenience.
> It seems that everyone is writing timers in this period :) I've my
> implementation too, resulting from preliminary off-list discussion
> with Pavel Vozenilek. It's similar to yours but I was not happy with
> the interface, and also wanted to make it interoperable with
> Boost.Date_Time without actually coupling with it.
> I appreciate a lot the enormous amount of work you are doing on this
> and other proposals (and it seems you are writing code faster than I
> can even comment on it :)) but I'm afraid this time we should refrain
> from submitting a component for which there's no existing practice. It
> can always be included later, even if criteria for inclusion will be
> much stricter.
I'm not sure if we are talking about the same thing. The cpu_timer
proposal is just for Boost, and Boost often is well ahead of existing
practice. That was part of the rationale for starting Boost.
The process is to first get informal comments (which is what this thread
is all about), make revisions based on those comments, and then submit
the library to Boost for formal review. Nothing unusual there.
Put another way, cpu_timer is just a wrapper around POSIX times() or
Windows GetProcessTimes(). cpu_time_reporter is a convenience wrapper
around cpu_timer. These underlying functions have been existing practice
for decades. All we are talking about here is the most appropriate way
to interface to them in a portable way. There is no intent to try to
meet other timer needs.
There is also discussion going on about more general questions regarding
a "system" or portability library. Having specific proposals for such a
library gives the discussion real library use cases to focus the discussion.