[mercury-users] SEC: UNCLASSIFIED:-

[Fergus Henderson]

On 30-Oct-2002, Ralph Becket <rafe at cs.mu.OZ.AU> wrote:
> Ian.Sykes at defence.gov.au, Wednesday, 30 October 2002:
> > 
> > My questions:
> >       Does time__clocks_per_sec return a meaningful value?
> 
> Yes - it is the number of units per second that time is measured in on
> a given platform by the time API.

I've been investigating this in more detail as a result of Ian's mail,
and unfortunately it turns out that it is not that simple.  There are
multiple time APIs and, confusingly, even when they return the same type,
they may return values measured in different units.

In particular, it turns out that values of type `clock_t' can have two
different meanings, depending on which routine returned them.  If the
clock_t is returned by clock(), i.e. Mercury's time__clock, then it counts
values measure in "clocks" which can be converted to seconds by dividing
by CLOCKS_PER_SEC (time__clocks_per_sec).  If the clock_t is returned
by times(), i.e. Mercury's time__times, then it counts "clock ticks"
which can be converted to seconds by dividing by CLK_TCK (or preferably
_sysconf(_SC_CLK_TCK)).  Unfortunately the Mercury standard library does
not include any interface to CLK_TCK or _sysconf(_SC_CLK_TCK), so you'll
need to use the C interface.

This incredibly confusing design has been standardized in Posix, but
the use of different meanings for clock_t is *not* well documented in
the Posix standard.  That's why I wasn't aware of it until now, and
why the Mercury standard library does not yet include any interface
to _sysconf(_SC_CLK_TCK).

> >       How is it fixed/determined?
> 
> By the OS.  The module time.m includes the C file <time.h> which in
> turn includes <bits/time.h> (on Debian, at any rate) which defines
> CLOCKS_PER_SEC as 1000000l (on my machine, at any rate.)

POSIX mandates that CLOCKS_PER_SEC by one million, regardless of the
actual clock resulution.

> >       What is its relationship to ElapsedRealTime given that, in my case,
> > it is a multiple?

None.

> It's simple: time__clock(ElapsedClockTicks, IO0, IO1) will unify
> ElapsedClockTicks with the number of clock ticks that have gone by since
> the start of the process (or some other, arbitrary, point before that.)
> 
> (ElapsedClockTicks / clocks_per_sec) is therefore the number of whole
> seconds that have elapsed since the start of the process.
> 
> If you want the number of centiseconds since this point, just use
> (ElapsedClockTicks / (clocks_per_sec / 100)).

This is true for time__clock, but naming this argument "ElapsedClockTicks"
would be misleading, since it measures *processor* time, not *elapsed* time
(i.e. it excludes time spent in other processes).
Ian Sykes was asking about the ElapsedRealTime returned by the time__times
procedure, and that one has no relation with time__clocks_per_sec.

P.S.
Unfortunately, that's still not the whole story.  I justed tested a
simple program use times() on one of our development machines, and it
seems to be buggy -- it returns values measured in seconds, not measured
in clock ticks.  It's seems unlikely that something as basic as this
could really be broken, so maybe I am missing something.  But my test
program works as expected on Suse Linux 7.0, Linux RedHat Linux 7.3,
Debian Linux 2.2, Digital Unix, and Solaris, so I guess it really is a
bug in the particular version of Debian Linux that we have installed
on that machine.  It's something to beware, though.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------