From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7536 invoked from network); 12 Dec 2022 05:01:46 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 12 Dec 2022 05:01:46 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 9911942438; Mon, 12 Dec 2022 15:01:39 +1000 (AEST) Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by minnie.tuhs.org (Postfix) with ESMTPS id B0AF742437 for ; Mon, 12 Dec 2022 15:01:35 +1000 (AEST) Received: by mail-pj1-f51.google.com with SMTP id hd14-20020a17090b458e00b0021909875bccso12715531pjb.1 for ; Sun, 11 Dec 2022 21:01:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kev009.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=pHruNDCL9rH+y0vaUnpRHmvanOTr/wL6urHDK0IWAi0=; b=Pn1zf93gGlSfnuZzOBKTSoq6TCENNx9bbZjyFUCsy7aPveXvyoFWwWqBR+nlrYCyls kTkYxxAfgkTC77Dguw7pPMVk1YmhjtuUvJLAjeXIdrsyTsg5xkJ95JC4eg4nkgWb0XSh 0DvrS+lgcEiC2Ag0a9u3Ap/ytRyLXuACGRH0o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=pHruNDCL9rH+y0vaUnpRHmvanOTr/wL6urHDK0IWAi0=; b=i8gDpKyx+0wEHprP4qFehK/L/NmM/4tlyWuyMuL63tOYSoWY5YzE6Ub03RMNsBhlWn X2n8QEkIy+62076WbD9wsyVKdg2MzOcxdVR1dqeKjLsDHH9w/o0dA0gGtwkmEU0Vg64F XT9pssqNoQRHRQMxMFsSyFm5mCxCZ5+7S49P+t38dnLt+JU+lsrILeia5Wqs7gLnHrEy Je9r/p+MYtLsu9YAyjdu9saQUwUVQgRV3XD1/gTjIwdFQgQVahCEtPSiwNZjR+CFyCGZ GYWwd1p4i/6QS9rNmuDmIyvdn2+Nq2NUxN4AAptGpKvMCmAPHoHPHCRd8YpUzIZ8OU/T 5/9Q== X-Gm-Message-State: ANoB5pkfmWKdT/+RHllgdLmvyRs/yDdS5BtzDytc33ziknc0ZUwvs29n jbcTyLGmmyY9j3T3Sn+ynHTcqZVGjSE6MPgX3nzkfA== X-Google-Smtp-Source: AA0mqf58TRXJffUODKdsOC5wuITHgYx+Y4TfKEny3mp7ugy8a/Huqiifje+TRTuzmWARHkEC/xvoosum8voZdUEJb2U= X-Received: by 2002:a17:902:b611:b0:189:1c94:99c3 with SMTP id b17-20020a170902b61100b001891c9499c3mr78925547pls.140.1670821234706; Sun, 11 Dec 2022 21:00:34 -0800 (PST) MIME-Version: 1.0 References: <20221211200327.GC8801@mcvoy.com> <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org> <20221212033453.GE8801@mcvoy.com> In-Reply-To: <20221212033453.GE8801@mcvoy.com> From: Kevin Bowling Date: Sun, 11 Dec 2022 22:00:22 -0700 Message-ID: To: Larry McVoy Content-Type: text/plain; charset="UTF-8" Message-ID-Hash: NXBK63JXIIOJJAMFF54K62D7PG2HZE6I X-Message-ID-Hash: NXBK63JXIIOJJAMFF54K62D7PG2HZE6I X-MailFrom: kevin.bowling@kev009.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Sun, Dec 11, 2022 at 8:35 PM Larry McVoy wrote: > > On Sun, Dec 11, 2022 at 08:09:32PM -0700, Andrew Warkentin wrote: > > On 12/11/22, Bakul Shah 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