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

[Kevin Bowling <kevin.bowling@kev009.com>]

On Sun, Dec 11, 2022 at 8:35 PM Larry McVoy <lm@mcvoy.com> wrote:
>
> 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.

Mach seems not incompatible to me to Windows NT ideas of layering,
especially in modern macOS guise, more so than a microkernel I'd call
it something like a "macrokernel" with a variety of ways to do
things.. dealer's choice for better and worse.  It is interesting to
note the success, often overlooked by more hardline *nix people, that
macOS (and iOS and tvOS and watchOS etc) is indeed mach (more so than
it is BSD as some people claim) and wildly successful.

> 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