[boost] Re: timer classes

From: Reid Sweatman (reids_at_[hidden])
Date: 1999-07-01 13:37:20

Just a minor cavil from someone who does most of his programming on Wintel
platforms:  the C and system timer functions aren't very reliable, because
they're at the mercy of the time-share schemes (which are different in every
version of Windows), and don't return very reliable numbers.  On Pentium and
better Intel processors, though, the Time-stamp instructions are available,
which directly read an _Int64 counter in the CPU that counts cycles since
start-up or reset.  The only inaccuracies in using these instructions are
those associated with the function-call overhead, assuming you've handled
thread-locking and such correctly.  Admittedly, this only works on a subset
of one brand of processor, but realistically it accounts for a large chunk
of market share.  I'd rather see such a version of the implementation layer
for Pentium systems than one that uses the standard system calls.

> -----Original Message-----
> From: Beman Dawes [mailto:beman_at_[hidden]]
> Sent: Thursday, July 01, 1999 6:13 AM
> To: boost_at_[hidden]; boost_at_[hidden]
> Subject: [boost] Re: timer classes
> 
> 
> At 10:13 AM 6/30/99 -0500, Ed Brey wrote:
> 
> >Email seemed somewhat boring, until Beman Dawes wrote:
> >>
> >>I would like to get some feedback on two timer and one progress
> >>reporting class before going to the trouble of documenting them.
> See
> >>http://www.boost.org/libs/timer/
> >
> >There are many good features.  Here are some aspects that could use
> >improvement, IMHO, however:
> >
> >- Progress display and timers seem to be unrelated.  They shouldn't
> >be kept in the same file.
> 
> You are right, of course, that logically they are unrelated.  The
> rationale for combining them was:
> 
>    *  Avoiding header proliferation.
>    *  In practice, programs that use progress_display also use
> job_timer.
> 
> Perhaps timer should be in its own header.  It is much more general
> that job_timer and progress_display which were originally designed
> for console programs only.
> 
> >- Hiding the implementation details for timer provides a bad
> tradeoff:
> >it requires an otherwise unnecessary heap allocation for each
> instantiation
> >of a timer.  It would be better to byte the bullet and put clock_t
> into
> >the timer class.
> 
> I really do want to divorce timer from its implementation. Rationale:
> 
>      * On some systems it won't be possible to use the C clock
> functions at all, yet it will be possible to implement timer using
> native functions.
> 
>      * Exposing clock_t means including <ctime> which includes two
> macros.  I dislike that.
> 
> So while I appreciate the comment, I will keep the implementation
> separate unless someone comes up with a killer argument not to.
> 
> >- Add a member function or constant to allow programatic access the
> >time limit of the implementation before overflow occurs.
> 
> Good idea.  Hum... How do you implement that using <ctime>? I will
> have to ask some C experts, but it looks to me like you just came up
> with a hole in the C standard!  I have sent a message to the
> committees asking for information.
> 
> Thanks for the feedback,
> 
> --Beman
> 
> 
> --------------------------------------------------------------
> ----------
> Just Tell Us What You Want...
> Respond.com - Shopping the World for You!
> http://clickhere.egroups.com/click/390
> 
> 
> eGroups.com home: http://www.egroups.com/group/boost
> http://www.egroups.com - Simplifying group communications
> 
> 
> 
> 

------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/boost
http://www.egroups.com - Simplifying group communications