Subject: Re: Multiprocessor with NetBSD ?
To: NetBSD-current Discussion List <firstname.lastname@example.org>
From: mike stone <email@example.com>
Date: 06/06/2001 14:24:20
> That's what some literature calls an "Associated Processor"
> configuration, in direct contrast to a "Symmetric MultiProcessor",
> and indeed in contrast to a multiprocessor (homogeneous or
> heterogeneous) in which there's one or more main processor as well
> as one or more specialised I/O processors.
that sounds familiar, and i'm happy to accept those definitions.
i also concede that under those definitions, i was using the term
my last post was a weak attempt to compare the relative merits of
AP -v- SMP. while SMP does have its strengths, it also has weaknesses.
and like any technology, SMP is best suited to a particular problem set.
AP also has strengths and weaknesses, and a range of problems for which
it happens to be useful.
my question is "how well does SMP support the work we're most likely
to do?" with the corrolary, "would AP provide equal, better, or worse
support for that same work?"
to me, it seems that people associate "multiple CPUs" with "SMP"
somewhat arbitrarily, but please allow me to insert massive
disclaimers at this point, as i do *not* want to shit on the shoes
of the NetBSD developers currently working on SMP code. that would
be snotty, stupid, and rude. mad props, guys.. you know far more
about the kernel than i do, which, in the meritocracy of hackerdom,
pretty much says it all. i'm thinking of tech journalists, Linux
kiddies on Slashdot, and other creatures that might one day evolve
into single-celled organisms.. the hordes who drag code into being,
and keep bad ideas on life-support forever, with the sheer force
of their ceaseless yammering.
my concern is that SMP may be equivalent to building a really great
formula-one racecar that will be used mostly for delivering pizzas or
plowing fields. i'd be happy to hear anyone's reasons for thinking
that SMP *is* the best route to go, because i'm not on an anti-SMP
crusade. i'd just like to feel comfortable thinking that NetBSD
provides a workable solution for the right problem, rather than an
elegant solution for the wrong problem.
> BTW, according to Blaauw & Brooks it is _incorrect_ to refer to the
> processor contention in accessing shared memory as the "von Neumann
works for me. memory contention is a serialization issue, and thus
falls under Amdahl's Law. i apologize for running the two ideas
together, if i did. my original point.. from which i admit i've
drifted.. was that adding CPUs doesn't give linear speedup. the
rest has been (largely) personal prejudice piped through /dev/soapbox.