[Openmcl-devel] CPU Usage

[Gary Byers]

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:

(loop
  (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
> http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel
>
>


_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel