Q: clock ticks versus clock clicks - worth enhancing?

1 view
Skip to first unread message

Bruce S. O. Adams

unread,
May 11, 1999, 3:00:00 AM5/11/99
to

I notice we currently have:

clock seconds - to determine elapsed realtime

clock clicks - to determine elapsed systemtime

and various format routines to translate between them.
The problem with clock clicks is that it is platform dependent.
If you wish to do some temporal measurement e.g. profiling at the TCL
level you have to use clicks and convert
to the less accurate seconds format. If you wish to retain the accuracy
you must use
the clicks format. However, this is platform dependent, so it cannot be
used to
compare values accross machines. Granted for profiling scripts can be
executed repetitively
and the longer a task takes the less the accuracy matters anyway.
What I would like to see is:

clock ticks - to return a platform independent
measure of elapsed time
(say since creation of the
interpreter)

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?
Regards,
Bruce A.


Cameron Laird

unread,
May 11, 1999, 3:00:00 AM5/11/99
to
In article <37381B26...@rmc-ltd.com>,

Bruce S. O. Adams <bruce...@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.
--

Cameron Laird http://starbase.neosoft.com/~claird/home.html
cla...@NeoSoft.com +1 281 996 8546 FAX

Roger E Critchlow Jr

unread,
May 11, 1999, 3:00:00 AM5/11/99
to
cla...@Starbase.NeoSoft.COM (Cameron Laird) writes:

> In article <37381B26...@rmc-ltd.com>,
> Bruce S. O. Adams <bruce...@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 --


Bruce S. O. Adams

unread,
May 11, 1999, 3:00:00 AM5/11/99
to

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.

Darren New

unread,
May 11, 1999, 3:00:00 AM5/11/99
to
Bruce S. O. Adams wrote:
> I was doing speccy programming. Surely even a modern palmtop could cope with
> that (even if encumbered by a dodgey M$ operating system :-).

All this assumes, of course, that the clock runs at a constant speed.
Not always the case in embedded hardware, but a reasonable assumption
for anywhere you'd likely to be using Tcl. :-)

--
Darren New / Senior Software Architect / MessageMedia, Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.

Bryan Kelly

unread,
May 11, 1999, 3:00:00 AM5/11/99
to
So after reading a few of these, let me jump in and show my ignorance.
Get the time in seconds and clock ticks,
wait a short period of time,
get time in seconds and ticks again.
Bounce seconds and ticks against each other and derive the number of ticks
per second.

You could do it once per run if you can afford a little time, or run it once
per machine and leave
a file somewhere with the results.

Okay, bash me,
Bryan


Donal K. Fellows

unread,
May 12, 1999, 3:00:00 AM5/12/99
to
In article <3738718F...@messagemedia.com>,

Darren New <dn...@messagemedia.com> wrote:
> All this assumes, of course, that the clock runs at a constant speed.
> Not always the case in embedded hardware, but a reasonable assumption
> for anywhere you'd likely to be using Tcl. :-)

There are embeddable processors where the clock frequency is in the
10s of kHz range (with the clock having absolutely nothing to do with
instruction processing...)

Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- The small advantage of not having California being part of my country would
be overweighed by having California as a heavily-armed rabid weasel on our
borders. -- David Parsons <o r c @ p e l l . p o r t l a n d . o r . u s>

Reply all
Reply to author
Forward
0 new messages