[Openmcl-devel] CPU Usage
gb at clozure.com
Thu Sep 5 22:12:37 UTC 2002
On Thu, 5 Sep 2002, Sven Van Caekenberghe wrote:
> While using openmcl 0.13 through ILISP with the build in TTY emacs (Mac
> OS X 10.2), dppccl is often using large amounts of CPU (30-40%) even
> when its idle. After a while things do tend to return to normal levels.
I assume that you saw these fluctuations by running 'top'.
OSX 10.2's top program supports '-d' and '-a' options, which seem to
be weird hybrids of each other (as if whoever implemented them got
halfway through and forgot which was which.) Top's '-a' option is
supposed to show cumulative counters relative to the time of its
invocation. Some are relative and some aren't, but the -a option
does show cumulative CPU% usage; without -a, top tends to show
CPU% over the last (default 1 second) sampling interval.
I ran top with and without "-a", in an environment in which a
dppccl from 0.13, a development version of pre-0.14, and lots of
other (mostly idle) programs were running. When I ran without -a,
I occasionally saw "spikes" in the >30% range associated with the
lisp from 0.13. When I added the -l option and logged the output
to a file, I got a slightly different view of things.
A program "30% of available CPU" in an environment where it's
about the only program that's at all runnable is a somewhat
different situation than a program that's squeezing other runnable
programs out of their share of CPU.
Other programs that were running (including an X server, which
should have been mostly idle) would sometimes jump up into the
12%-15% range; I don't believe that they did so because of
some horrible busy-waiting loop that nobody's ever notived ...
> Is this normal?
I think that sampling anomalies are normal, and I think that the
"spikes" that show up in some cases in 'top' are more sampling
anomalies than anything else.
> Is there some polling going on?
Sort of. If no threads are ready to run, the lisp scheduler will
block in #_select for up to 1 tick (1/100th of a second.) If there's
a single thread waiting for input (e.g., the lisp is just sitting at
the listener prompt), this is very much like:
(find-ready-thread-and-retunrn-if-found) ; single thread waiting
; for input, so this fails.
(#_select (file-descriptors-waiting-for-input) ... ... (1 tick)))
There's a bit of additional bookkeeping activity going on in that loop;
it's using -some- CPU, but it's not exactly busy-waiting.
In 0.13 and earlier, executing lisp code is interrpted 100 times a
second through an "alarm" timer. Delivery of an "alarm signal"
has the unfortunate side effect of terminating the #_select call
prematurely (so the lisp will sometimes repeat the loop.) The
pre-0.14 I was working on uses a different mechanism. When measured
with top's -a option ("top -u -a 5"), the two lisps showed virtually
identical CPU utilization (I got around 2.5% in each case.)
> Are native threads being used?
No, but the plan is to phase them in over the next few OpenMCL
releases (details forthcoming; if anyone's curious, ask.) Using
native threads will eliminate much or all of that "additional
bookkeeping activity", and should enable the CPU utilization when idle
to drop to virtually 0.0.
There are tradeoffs: switching into and out of the OS kernel to switch
between threads can't be as efficient as doing it "manually" is.
> I am just curious. Would openmcl make a good application server?
I don't know; I'm not entirely sure what an application server is
in this context.
> Sven Van Caekenberghe - mailto:sven at beta9.be
> Beta Nine - software engineering - http://www.beta9.be
> .Mac - svc at mac.com - http://homepage.mac.com/svc
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
Openmcl-devel mailing list
Openmcl-devel at clozure.com
More information about the Openmcl-devel