[Openmcl-devel] 131 into 87 does not go
Gary Byers
gb at clozure.com
Thu Sep 10 23:14:13 PDT 2009
Were you running on a real-time OS ? (No, you weren't.)
Unless you think that the function used to measure run time is doing
the arithmetic incorrectly, there probably isn't anything surprising
about the fact that you're seeing a reported run (CPU) time that's
just a little over .1 seconds and a real (wall-clock) time just a
little under .1 seconds. There are any number of possible reasons for
this sort of (0.044 second) discrepancy (including the possibility
that the OS decided to run some other process for ... oh, 0.044
seconds or so, right around the time that code invoked by TIME decided
to ask about the process's run time. Or the lisp GCed then. Or
you're seeing the cumulative roundoff error from the OS's run time
accounting. Or ...
If the total time involved was much larger and CPU/run time
consistently exceeded real time on a single CPU, then there'd be
something odd about that. (Yes, it's "odd" that reported CPU times
on a single CPU system can exceed reported wall-clock time, but it's
not uncommon.)
On Thu, 10 Sep 2009, Arthur W Cater wrote:
> There's something odd about this ...
> ? (time (LOSE-BY-SCHICHO @k5 3))
> (LOSE-BY-SCHICHO @K5 3) took 87 milliseconds (0.087 seconds) to run
> with 1 available CPU core.
> During that period, 129 milliseconds (0.129 seconds) were spent in user mode
> 2 milliseconds (0.002 seconds) were spent in system mode
> 303,064 bytes of memory allocated.
>
>
>
> using
> Welcome to Clozure Common Lisp Version 1.3-r11960M (DarwinPPC32)!
>
> Arthur
>
>
More information about the Openmcl-devel
mailing list