[TUHS] the true reason why c++ always wins
Theodore Tso via TUHS
tuhs at tuhs.org
Thu May 28 21:34:55 AEST 2026
In addition to Bakul's observation that microkernels don't really
solve the interruptible system call problem, the other thing I'd note
is that microkernels have an economics problem, and that's something
that you've largely ignored in your arguments.
I'm trying to remember to exact meeting, but if I recall correctly it
was a file system meeting that was called by the DOE at Sandia
National Labs, where they were trying to motivate the industry into
investing in a massive parallel file system because it was patriotic
duty to help the DOE build the next generation nuclear bombs, which
they would have to simulate since the test ban treaty wasn't letting
them test real ones. (Spoilsports....) They also explained that they
couldn't pay for the investment, but surely the market would buy such
a product if the industry were to invest in this critical peace of
technology so we could continue to build nukes. Needless to say, the
industry didn't bite. At the meeting, a lot of people disputed the
assertion that the commercial market had the need for the kind of
specs that the DOE was proposing.
Anyway, at a side conversation the topic of microkernels came up, and
Rick Rashid, who was at Microsoft at the time, stated that he didn't
believe that microkernels were really going to be viable, for the
simple reason that while it was *possible* for microkernels to be as
efficient as the monolithic kernel design, it took a lot more time and
engineering to implement, since it requires a lot of really clever
tricks. And in the intervening time, the people investing in the
monolithic kernel could make further performance improvements and add
new features, and the microkernel could simply never keep up.
And yes, you said that it's all about engineering, and maybe we should
give up on some of the performance to get a better architecture. But
unfortunately the market and customer choice doesn't work that way.
There's a reason Oracle used to plaster the back cover of Business
Week magazines with Oracle DB benchmark numbers. (I'll ignore here
whether the benchmark numbers were real, or very carefully curated
benchmarketing numbers.) And I've personslly seen that users will
always choose the file syystem with the best possible performance
numbers --- whether they need the performance or not, and whether
their workload has any reationship with the actual workload that they
need to run. That's why the word "benchmarketing" exists in the lexicon.
The other thing to remember is that the economic imperatives change
over time. In the early days of Unix, or even the early days of
Linux, high CPU core counts were not really economically viable. Or
if they were, it was massive tradeoffs like NUMA which had other
tradeoffs. In those early days, Linux's sweet spot was scale out, and
not sale up, where you would use hundreds or even thousands of cheap
PC class hardware, instead of expensive iron systems because they had
a better price / performance reason. Google's early system of bare
motherboards sitting on cardboard as an insulator may have been ugly,
but it was way cheaper than buying Sun E10K's.....
Of course, the technology and economic imperatives keep changing, and
Google doesn't do bare motherboards sitting on cardboard any more.
For mobile devices (which weren't a thing in the early days of Unix or
even the early days of Linux), power efficiency absolutely matters.
So having tons of kernel threads sitting in polling loops might not
really be viable. Even in data centers, where that sort of thing was
more interesting, now power efficiency is more important than CPU
efficiency, because hyperscaler needs to save their power and cooling
budget for GPU's, and in many cases, the CPU is sitting their
twiddling its fingers while the GPU is getting on with the important
work of vibe coding a Snake game. (And of course, getting Open AI and
SpaceX to their IPO, and to make sure Google can have a truly stunning
of demos at Google I/O.)
The TL;DR of my whole reaction to your argument is, "It's
complicated...." :-)
- Ted
More information about the TUHS
mailing list