[Openmcl-devel] CPU Usage

Fri Sep 6 02:32:47 PDT 2002

Thanks for the knowledgeable response, very interesting indeed. Top and 
CPU Monitor seem to have a life of their own sometimes, and can be hard 
to interpret. The behavior that I described is real however (I got it 
again today) and although it comes back to normal, fact is that most 
other applications don't do this.

BTW, by 'application server' I mean long running server side processes 
like portable aserve and others like that (Java 2 Enterprise Edition 
things). I think Lisp could have a niche there (see also Paul Graham's 
articles). In those case both good memory usage (no leaks, stable heap 
sizes) and good cpu citizenship (no loose threads) are important.

On Friday, September 6, 2002, at 12:12 AM, Gary Byers wrote:

>
>
> 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
>>
>>
>
>
--
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