Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!ncar!hsdndev!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.sys.apple2
Subject: Re: HLLs vs. Assembly
Message-ID: <15682@smoke.brl.mil>
Date: 3 Apr 91 00:07:05 GMT
References: <13156@ucrmath.ucr.edu> <1991Mar30.080418.16299@ee.ualberta.ca> <13202@ucrmath.ucr.edu>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 32

In article <13202@ucrmath.ucr.edu> rhyde@gibson.ucr.edu (randy hyde) writes:
>OSes are the backbone of a machine.  Furthermore, they are *pure overhead*.

Not so -- operating systems almost always provide support services,
such as I/O management, for applications.  If the OS didn't do it,
the application would have to.  There is great value in having a
single consistent implementation of such services, even if task
scheduling were not needed.  Even MS-DOS systems have a "BIOS" that
is designed to provide basic I/O services, not overhead.

We have graphical performance monitors for a lot of our UNIX systems;
these show what percentage of processor time is spent in various "modes".
For example, "user" mode is pure processing without OS involvement,
while "system" time is spent in the kernel, either on behalf of
applications or in genuine overhead, and "idle" mode is time when the
processor is not needed for anything.  We find that a lightly-loaded
system spends typically less than 1% of its processing in the kernel
(due to always having a bunch of daemons handling network traffic,
etc., not to mention having to run at least the monitoring process,
it cannot be precisely 0%, which is the theoretical ideal).  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.