Non-member submission from [Brian Logan <bsl@cs.nott.ac.uk>]
I have been trying to write some procedures to time the execution of Poplog
code.
systime has fairly poor resolution (1/100th of a second), so I happily wrote
some timing procedures using sys_timer and trap procedures. This didn't
work, and on closer reading of REF TIMES I discovered that the maximum
resolution of the asynchronous trap procedures created by sys_time is also
1/100th of a second.
usecs_or_false -> sys_timer(ast_p, flags)
usecs_or_false -> sys_timer(ast_p)
This procedure and its updater provide multiple real or
`virtual' interval timers, each attached to a particular
asynchronous trap procedure ast_p that gets run when the timer
expires.
and then ...
usecs may be a biginteger, the largest time allowed being
pop_max_int seconds plus 999999 microseconds (i.e. the seconds
part of usecs must be within the range of a simple integer). The
smallest time allowed is 0, but assigning a non-zero time value
smaller than the resolution of the system clock sets a timer for
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
that resolution (e.g. 1/100th second on VAXen and Sun-4 systems,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1/50th sec on MC68000 systems, etc). A zero time value causes
the timer to expire immediately.
which is what seems to happen. When I created timers with what I thought
was microsecond resolution, I was surprised how fast my programs seemed to
be running (based on the number of timer ticks). When scaled four orders of
magnitude, things made more sense.
Is there any way to get better than 1/00th of a second resolution timing in
Poplog?
Thanks
-- Brian
Brian Logan, School of Computer Science & IT, University of Nottingham
Email: bsl@cs.nott.ac.uk, Phone: +44 115 846 6509, Fax: +44 115 951 4254
|