DN476658978

Subject: Re: Q: clock ticks versus clock clicks - worth enhancing? - DN [1]

"Bruce S. O. Adams" <bruce.adams@rmc-ltd.com> - 11 May 1999 - comp.lang.tcl

 Roger E Critchlow Jr wrote:

 > claird@Starbase.NeoSoft.COM (Cameron Laird) writes:
 >
 > > In article <37381B26.DE95072B@rmc-ltd.com>,
 > > Bruce S. O. Adams <bruce.adams@rmc-ltd.com> wrote:
 > > >
 > > >I notice we currently have:
 > > >
 > > >    clock seconds                - to determine elapsed realtime
 > > >
 > > >    clock clicks                    - to determine elapsed systemtime
 > >                       .
 > >                       .
 > >                       .
 > > >This would provide a regular heartbeat  (e.g one tick every 50ms) and
 > > >allow comparasion of
 > > >times accross platforms.  This could probably be hacked out of the
 > > >existing clicks code without
 > > >much difficulty.  It could also be used for some types of
 > > >synchronisation, though thats what
 > > >events are for.  Anyone care to comment?
 > >                       .
 > >                       .
 > >                       .
 > > Yup.  It comes up every five months or so.  I'm all
 > > for it (or a variation).  I don't find any record of
 > > a Scriptics person responding to the idea.
 >
 > I don't know.  It seems that the ANSI standard C solution of exposing
 > the click granularity might be better than trying to simulate a preordained
 > granularity everywhere.  As soon as you pick a reasonable granularity,
 > you'll find a machine, for instance a palmtop, which cannot compute that
 > granularity to save its life, because its internal clock is running at
 > 3.141592MHz.
 >
 > So if
 >
 >         clock clicks
 >
 > is implemented by the ANSI clock() function (or moral equivalent), then
 >
 >         clock clicksPerSecond
 >
 > could simply return the ANSI CLOCKS_PER_SEC value.
 >
 > -- rec --

 I like standards compliance (even if its not my national standard :-).  This is
 a definite
 must.  Since it comes so close to implementing 'clock ticks' as previously
 defined
 why not include that in terms of 'clock frequency' to save a few lines been
 retyped
 endlessly.  The value mentioned above 50ms was based on my memory of the Z80
 when
 I was doing speccy programming.  Surely even a modern palmtop could cope with
 that (even if encumbered by a dodgey M$ operating system :-).  Still, point
 taken.  We
 could always add a command 'clock pulserate' which would set the tick speed and
 throw
 an error if it was too fast for the hardware.  How about that?
                 Regards,
                             Bruce A.