Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!linac!att!princeton!phoenix!kadickey
From: kadickey@phoenix.Princeton.EDU (Kent Andrew Dickey)
Newsgroups: comp.sys.apple2
Subject: Re: HLLs vs. Assembly
Message-ID: <7830@idunno.Princeton.EDU>
Date: 3 Apr 91 06:14:36 GMT
References: <1991Mar30.080418.16299@ee.ualberta.ca> <13202@ucrmath.ucr.edu> <15682@smoke.brl.mil>
Sender: news@idunno.Princeton.EDU
Organization: Princeton University
Lines: 41

In article <15682@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
    [Lots deleted...]   
>With
>numerous time-sharing tasks heavily competing for system resources,
>we nevertheless often attain "user" mode utilization over 90%, and on
>our multithreaded applications we have been able to attain around 99%
>"user" mode processing when the application is crunching numbers and
>not doing I/O concurrently.
>
>Thus, system overhead, at least on our UNIX systems, is close to
>negligible, even if one doesn't allow for the convenience of having
>the I/O, IPC etc. services that the OS provides.  And the vast
>majority of the code executed by the UNIX kernel is written in C.
>Efficiency arguments about C versus assembler for the bulk of an OS
>kernel are thus spurious.

Doug misses an important point here in what those numbers mean.  Unix uses
timer interrupts to determine when to switch from one process to the next
(so one doesn't monopolize the CPU time).  After a program has been running
for more than N clock ticks, that process is preempted and moved to the back
of the queue (all of this is basically right, but there are a lot more
subtleties to it all).

Those numbers that Doug is quoting are calculated simply--when a timer
interrupt occurs, the system merely figures out what state the machine was
in when the interrupt came (either system or user) and increments a counter.
However, there are times when interrupts are not enabled!  Thus, the
interrupt cannot occur at those times, and so the numbers calculated are not
exactly right.  In fact, during a context switch, these interrupts will not
occur, so those numbers do not include times the system is taking to switch
among processes (on most systems).  Those numbers are really only meaningful
in finding out whether the computer is spending a lot of time in the kernel
calls (like read(2), write(2), pipe(2), etc.) and not in simple OS overhead.
Granted, Doug's system may do the numbers absolutely correct (I don't know
what he's running), but I wouldn't bank a lot on the validity of the numbers
he's quoting.

Unix has an incredible amount of overhead.

Kent
kadickey@phoenix.Princeton.EDU