I suspect the answer is simply 'no'. This is an OS constraint that
poplog can do nothing about. I just checked back some ancient history
(seems to be my role on this list :-) ), and discovered in the COGS
$poplocal some libraries from 1985 which addressed exactly this problem
- but that that was in the days when the standard pop functions had a
resolution of 1 second, and the libraries externally load the c
setitimer routines, which allow the time to be specified in
microseconds, but have an effective clock of 100ths of a second. In
other words, what you see in the current system is the effect of those
libraries having migrated their way into poplog, sometime in the
intervening 17 years!
The only thing I can suggest is that averaging over multiple runs of
your code would give you higher resolution figures...
Roger
Aaron Sloman wrote:
>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
>
>
>
>
|