Re: multi/tasking/processing
- To: rideau@xxxxxxxxxxxxxx
- Subject: Re: multi/tasking/processing
- From: Soft Wings <moth@xxxxxxxxxxx>
- Date: Wed, 16 Aug 1995 20:48:34 -0400
- CC: MISC
- In-reply-to: <9508162300.AA07984@clipper.ens.fr> (rideau@clipper.ens.fr)
Francois-Rene Rideau:
Nano- or Micro-, they are the same. The principle of a kernel
itself is deeply broken. What is a kernel ? Just some overhead to
dispatch routines at run-time. It just has no point. Code should be
bound whenever the binding is known, not before (not possible!),
not after (and at least, just once, not once per call).
Er.. how do you re-use resources used infrequently by processes?
Systems which require the programmer to manage these sorts of
efficiency constraints are nice and fast when properly tuned, but
they're painfully clunky until then.
What good is impressive massive speed if you're spending most of your
time waiting for it to be available [the case when you're using an
application in an environment different from what was originally
intended], or when you have to pay hundreds of thousands of dollars
per year to keep the thing cooking properly [the case when you have
dedicated programming staff on the job of tuning the application]?
In the long run, you're going to get a lot more in the way of speed by
paying attention to bounds on computational time and space (O(1) is
better than O(n)) than you are on reducing constant factors. Focus on
the constant factors only when they become critical to your
application.
And, when that time comes, question your fixed assumptions.
--
Raul