[TUHS] Re: Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives?

[Larry McVoy <lm@mcvoy.com>]

On Sun, Dec 11, 2022 at 08:09:32PM -0700, Andrew Warkentin wrote:
> On 12/11/22, Bakul Shah <bakul@iitbombay.org> wrote:
> >
> >
> > Agree that clear code is preferable to complicated code. But in practice
> > people sacrifice clarity for performance improvement all the time. Look
> > at the kernel code of any modern os. Everybody pays lip service to this
> > but most anything other than toy programs ends up getting needlessly
> > complicated over time. As an example, building "Unix as a service" as
> > user processes on top of a small microkernel could provide the same
> > functionality using much clearer and much less code but it would be
> > slower so we don't do it. Plan9 sort of went in that direction and it
> > is much simpler (but that could also be because it is not hacked on so
> > much).
> >
> 
> It's not necessarily true that microkernels are significantly slower.
> They mostly got that reputation because of Mach and kernels like it
> with their heavyweight IPC. Lightweight microkernels like QNX and the
> L4 family generally have significantly better performance (in fact,
> QNX 4 outperformed SysV/386 back in the 90s on certain benchmarks, and
> a proof-of-concept network driver on a current version of seL4 is
> significantly faster than a Linux network driver).

I was friends with one of the 3 people who were allowed to commit to QNX
kernel, Dan Hildebrandt (RIP 1998).  Those 3 people actually understood
the "micro" in "microkernel".   Early versions of QNX kernel fit in
the 4K instruction cache and left space for user programs.  They had
benchmarks that measured cache misses and refused commits that added to
the number of cache misses.

I met Dan because I had 10 terminals on a 80286 with I think 256KB
of memory and we were all editing and compiling and it worked way the
heck better than a 11/780 with 4MB with 30-40 students trying to do the
same thing.  I just wanted to talk to the people who made that possible,
it was after I had made a connection to Dennis.  The early QNX people
were special.  Dan and I had many conversations about the mono kernel
vs micro kernel, it was super fun because we weren't trying to convince
each other, we were comparing approaches.

I've never seen a team like Dan's team that cared as much as they did
about "micro" actually being micro.  That's the only way that that
approach works.  I can not state that enough, if you want to have a
micro kernel with message passing, if you don't fit in L1 cache,
you are a joke compared to a mono kernel.  You have to embrace
micro.

I had hoped that Mach would be like that but it was a giant mess.  I know
my opinion is not liked but I so wanted to like Mach, read the papers,
loved it, then read the code, hated it, a few years ago I was working
with the BSD team at Netflix, looked through the VM system from Mach
and it was a mess, it was the exact opposite of my experience at Sun
where I looked and looked and things came in focus and it made sense.
The Mach stuff has never made sense to me, I know Clem says it was a
research platform, OK, but the platform never got to a nice clean place.

If you think of microkernels and think Mach is it, nope, look at QNX.
-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat