Millisecond Clock Resolution
johnm at wdi.disney.com
Tue Apr 21 19:23:07 UTC 1998
>By the way, have you noticed that all these timings have a precision of
Squeak's Time millisecondClockValue primitive is typically implemented
using a convenient OS time function such as the ANSI C "clock()"
function. On the Mac, this function uses a hardware clock originally
based on the vertical retrace of the display, with a resolution
of 1/60th of a second. I recently made the Mac VM use a higher resolution
timer, allowing accuracy down to the millisecond. (This will be
be in the Squeak 2.0 release.)
I'm hoping that Ian and Andreas can find similar higher-resolution
clock functions to use in the Unix and Win32 VM's. (Andreas: Note
that windows has a high res clock called something like Timer.time(),
documented in the Multimedia API's.) However, not all platforms
will support high resolution clocks, or the overhead of using a
high resolution clock may be high enough to degrade Squeak's
performance unacceptably. Historically, Smalltalk's millisecond
clock has had only 1/60th second accuracy.
My big motivation for trying this is in anticipation of Stephen
Pope's MIDI primitives. I'd love to be able to support real-time
MIDI music applications with all the event scheduling implemented
in Squeak. The Squeak garbage collector pauses are sufficiently
short on a fast machine to contemplate doing this (under 10 milliseconds
on a 110 MHz PowerPC and under 3 milliseconds on the new G3 Macs).
Stephen's MIDI performance benchmark is a drum roll that starts at
ten drum hits per second and smoothly accelerates to twenty hits
per second. (Stephen: correct me if I'm wrong.) I believe that
if the occaisional hit is 3 milliseconds late--or even 10 milliseconds
late--due to a GC pause that this will still sound smooth, although
I know the ear is quite sensitive to small deviations in timing).
If 3-10 milliseconds isn't good enough, the GC pause time can be
tuned downwards (at the cost of more frequent GC's).
More information about the Squeak-dev