Re: [boost] [system][timer] CPU timer first draft

From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-06-25 14:56:02

Jeff Garland wrote:
> Beman Dawes wrote:
>> 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
> 
> A few thoughts:
> 
> 1) long long isn't portable -- use boost::int64_t instead

OK, changed in my copy.

> 2) get_process_times compile fails on Linux -- fairly obvious issue
> here...I'm guessing you are testing on Windows :-)

Fixed. Vault .zip updated.

Yes, I was testing mostly on Windows. I tested on a Mac, and then forgot
to retest after making some changes. It is working now on my Mac, but I
don't have a running Linux system to test on.

> 3) I see some major overlap in your plans with Boost.Process.  You
> are providing what amounts to a a simplified form of what I what
> Julio is doing in his SOC project.  You might have a look at Julio's
> current design page and provide feedback:
> 
> https://boost-consulting.com:8443/trac/soc/wiki/process/DesignThoughts
> 
> 
> I believe he would treat the various times you are measuring as
> attributes of the process class.  So the code would be something
> like:
> 
> bp::cmdline cl("...do something..."); bp::generic_attributes
> attrs(cl);
> 
> bp::launcher l(attrs); bp::child c = l.start();
> 
> while (!c.exited()) { time_duration wall = attrs.wall; time_duration
> user = attrs.user; ... };

The interface for my example is one line of code:

   boost::system::cpu_time_reporter tr;

So while it might be implemented using Julio's process design, 
cpu_time_reporter provides a completely packaged solution. Unless I 
missed something (always possible!), I don't see process as providing 
the same thing.

> 
> 4) Eating exceptions:
> 
> I don't like this code.  I've been burned a few times by code that
> does eats exceptions....

Throwing exceptions from destructors is usually considered a no-no. Note 
that it is possible to use explicit calls to stop() etc., and detect 
that an error occurred.

I guess someone could make a case that exceptions should be thrown 
except in the destructor. I'll have to think about that.

>> 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.
> 
> I'm not so sure, but I agree we should continue on both tracks for
> awhile.
> 
>> 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.
> 
> For the moment, I mostly see things that overlap other current
> library efforts -- error codes excepted. That said, I really applaud
> the effort.  In my view, Boost has being a piecemeal design OS api
> portability -- as an example, we have 3 libraries that retrieve clock
> time values from the system clock (thread, date-time, timer).

timer should be retired. threads should use date-time facilities. If 
cpu_timer is better implemented by calling date-time or process, that is 
OK with me, but I really like the simple cpu_timer and cpu_time_reporter 
interfaces. A user should not have to master a complex library just to 
write what amounts to one line of code.

> I
> really think we would make a major advance if Boost.system would be
> focused on providing a 'low-level' portable API and then all the
> 'higher layer' libraries could use the elements of Boost.system that
>  they need.  This would be kinda like Boost.Config at the system api
> level. Then Boost.system would be the first point of porting Boost to
> new platforms.
> 
> There are some issues.  Some libraries need their portability
> functions to be all header -- others might prefer a library based
> approach.  At what point do we add to Boost.system as opposed to
> providing the function in the the library -- like the filesystem
> code?  And, of course, code gets more scattered around in the boost
> tree.

Well, the error encapsulation really doesn't fit in any other single 
library, so at that point the camel's nose is under the tent and so we 
might as well acknowledge "system" as a small library and see what else 
fits into it, I think.

>> Note that I did use Boost.Date_Time components. That was because
>> I'm not
> ^^^^ missing a not
>> very familiar with Boost.Date_Time, and wanted to initially
>> concentrate on getting the desired results. Advice on how to best
>> make use of Boost.Date_Time would be appreciated.
> 
> Overall, the intent of the Boost.date_time types is to be efficient
> wrappers around core types (eg: integers) that provide the additional
> functions you would expect in a time representation.  You could
> probably replace your microseconds_t type with
> boost::posix_time::microseconds with little or no loss of efficiency.
> By returning a microseconds from functions like wall() the user can
> use the date-time streaming operators directly including the output
> formatting strings associated with time duration.  I believe this
> would also eliminate the the double-based precision issues in the I/O
> code.

That sounds like an improved way to implement cpu_time_reporter, and 
offers other user benefits too, I would guess.

>  One problem I see is that date-time doesn't have an easy way
> to do set-precision on i/o...something it probably needs.

My guess is that control over precision is something users really will want.

> Anyway, once you have a version that compiles on Linux I can take a
> shot at replacing this and seeing what happens...

That would be great! The refreshed .zip should work for Linux; if not 
let me know.

Thanks,

--Beman