Boost logo

Boost :

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
> >>
> >
> >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...
> - Shopping the World for You!
> home:
> - Simplifying group communications

------------------------------------------------------------------------ home: - Simplifying group communications

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