Gerhard Adam wrote:
My original question is completely answered, but I've got a corollary
question now. I understand the concept of MP overhead perfectly. If one
guy can do a >job in two hours, it's unlikely that two guys could
accomplish the same thing in one hour. So I understand why in aggregate
a 5-way box is not five times >as fast as a 1-way box.
I would modify the analogy slightly as follows:
Imagine two guys working on two projects, but having to share tools.
How much time is lost in having to wait for a tool to become available,
or to communicate with one another to see who has the tool, etc. It
isn't the task itself that consumes the time, but the coordination
behind every action that elongates the activity.
In short, the answer is that the MP effect is in the "hardware" (using
the term loosely) operation of the CP(s) in coordinating the actions
that are largely invisibile to the operating system.
depends on the granularity of MP consistency .... in 370 cache machines the
overhead was significant ... baseline started out slowing each processor
down by 10% (in a two-way configuration) just to allow for cross-cache
signaling ... i.e. 2-way was 1.8 times processing of a single processor.
Any actual handling of cross-cache invalidation/coordination was additional
slowdown.
3081 was only going to be a two-way offering ... and there wasn't going
to be any uniprocessor. In large part because ACP/TPF (at the time) didn't
have multiprocessor support ... they came out with 3083 ... which was
a single processor ... that had processor about 15percent faster than
3081 processor (being able to eliminate the cross-cache handling).
The 3084 4-way ... was three times as bad as a 3081 2-way (each processor
cache having to listen to 3 other processors caches ... rather than just
one other). In that time-frame ... both VM and MVS had some amount of
kernel storage restructuring to make things aligned on cache-line
boundaries and multiples of cache-lines (attempting to avoid two
different kernel storage structures overlapping in the same cache
line ... possibly being used by two different processes
concurrently ... resulting in significant cache-line trashing).
The claim was that the kernel storage restructuring for cache-line
sensitivity improved overall thruput by something like five percent.
lots of past SMP related postings
http://www.garlic.com/~lynn/subtopic.html#smp
including mentioning Charlie inventing compare&swap at the
science center
http://www.garlic.com/~lynn/subtopic.html#545tech
I've claimed in the past John's work on 801/risc in the mid-70s
http://www.garlic.com/~lynn/subtopic.html#801
was at least partially motivated by reaction to the extreme hardware
complexity (and failure) of the Future System project
http://www.garlic.com/~lynn/subtopic.html#futuresys
there was also a strong drive that 801/risc would never support
multiprocessing and cache consistency ... reaction to the enormous
thruput penalty seen in 370 (and later) mainframe multiprocessor cache
consistency implementations.
the lack of cache consistency and multiprocessor support was
one of the motivations driving us to do the ha/cmp product,
as a way of getting scale-up
http://www.garlic.com/~lynn/subtopic.html#hacmp
and related old email about "medusa" effort (cluster in a rack)
http://www.garlic.com/~lynn/lhwemail.html#medusa
however at the time ... we also participated some in the SCI
activity ... we just didn't have a processor that we could
build any machines from ... recent post mentioning SCI
http://www.garlic.com/~lynn/2007g.html#3 University rank of Computer
Architecture
somewhat related past thread (from this mailing list) discussing the issue and
citing some 2084 LSPR ratios
http://www.garlic.com/~lynn/2006l.html#30 One of two CPUs - the pros & cons
http://www.garlic.com/~lynn/2006l.html#41 One or two CPUs - the pros & cons
http://www.garlic.com/~lynn/2006l.html#43 One or two CPUs - the pros & cons
http://www.garlic.com/~lynn/2006l.html#47 One or two CPUs - the pros & cons
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
