Re: Scaling OSes fro multiprocessors, semaphores et al.
>But only slightly. I would argue it is very straightforward
>for any competent software engineer with a bit of experience.
Having watched benchmarks that had system (spent in the OS instead of in the application) time go up from 10% up to 60% for the leap of 2 to 4 processors on an NT system, effectively eating up the extra CPU (with CPUs with 256MB of secondary cache; it's better with larger caches), I think that either Microsoft software engineers have only very recently acquired 'a bit of experience', or you're underestimating. Mind you, that was on *throughput*, i.e. running only single CPU jobs, not even MP pograms.
a) you were starting off with a Unix base OS; already quite
capable for multiprocessing using time multiplexing on one CPU,
and for quite some time. The leap from multiprocessing well on one
CPU to doing it on more CPUs is smaller than what you get starting
off with other OSes.
b) semaphores are only one aspect, and there are *many* such aspects
in the OS. Many small tasks add up to a very large one -- tracking
down bottlenecks takes time; once you find one you can either
be lucky, i.e. it's easy to fix things, or unlucky, i.e. you have
to redesign critical parts of the OS. You usually aren't always
lucky ;).
c) Semaphores aren't the hardest part. An efficient scheduler that
doesn't trash the processor caches, and doesn't starve any
processes (especially those producing data other processes
are waiting for), and handles interrupts well, is. So is avoiding
false sharing in large parts of the OS routines. Forgetting even
one instance of this can kill you. And I'm not even mentioning the
fact that, if you have undetected potential races in software
pieces, you can expect to have a lot of trouble debugging it on
a fully loaded machine with lots of CPUs, so it's even more
difficult to make all of this robust. |
