[Openmcl-devel] more precise timing values?

[Gary Byers]

On Sat, 5 Oct 2013, Florian Dietz wrote:

> Yes, I typed rlet. I just copied the entire piece of code.
>
> I am running this program on windows.

Huh.  Who'd have guessed (and how would they have guessed) ?

CCL:CURRENT-TIME-IN-NANOSECONDS was added to CCL in 1.9; it was
present in the trunk for several months before 1.9 was released.  It's
defined on Windows, so if I had to guess (and I do ...) I'd say that
you're likely running an older version.

The actual resolution of the Windows timing facility that
CURRENT-TIME-IN-NANOSECONDS uses is very low (on the order of a millisecond,
IIRC); if I also remember correctly, CURRENT-TIME-IN-NANOSECONDS and
GET-INTERNAL-REAL-TIME both use the same Windows primitive, which reports
the current time in 100 nanosecond intervals.

? (let* ((start (current-time-in-nanoseconds)))
     (- (current-time-in-nanoseconds) start))
0               ; not reallly
? (let* ((start (current-time-in-nanoseconds)))
     (sleep 1)
     (- (current-time-in-nanoseconds) start))
1000000000      ; an amazing coincidence if so ...

I don't know of any higher-resolution way of measuring time on Windows.

In general, high-resolution times and timers are good things, but there are
tradeoffs involved.  In CCL, INTERNAL-TIME-UNITS-PER-SECOND is 1000 in 32-bit
versions and 1000000 in 64-bit versions, and this is mostly based on the
belief that millisecond times and time intervals are less likely to involve
bignum arithmetic (which can affect timing results) than microsecond times
and intervals would.  Whether this is significant or not, the accuracy of
the result (whatever units it's expressed in) depends on the actual resolution
of whatever is being used to measure it.  (If INTERNAL-TIME-UNITS-PER-SECOND
was 1000000 on Win32, you'd probably still see times and time-intervals that're
only accurate to ~1 millisecond.)


>
>
> On 05.10.2013 17:18, Stas Boukarev wrote:
>> Florian Dietz <Florian.Dietz2 at gmx.de> writes:
>> 
>>> Thank you for the quick answers. Unfortunately, neither of these work
>>> for me.
>>> 
>>> (rlet ((tv :timeval))
>>>    (ccl::gettimeofday tv)
>>>    (values (pref tv :timeval.tv_sec)
>>>            (pref tv :timeval.tv_usec)))
>>> gives me 'Error: value :TIMEVAL is not of the expected type MACPTR.'
>> Are you sure that you typed rlet and not let?
>> 
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>