johnl@ima.UUCP (05/09/85)
Has anybody ever claimed there was any advantage to multiprocessors other than
price or (at the high end) constructability? If so, I don't believe them
either. We now have about 40 years experience in programming uniprocessors
and, relatively speaking, none in multiprocessors (unless you want to count APL
and its relatives as implicitly programming multiprocessors.) That's a lot of
catching up to do even if programming parallel computers was as easy as
programming serial processors, which it isn't.
(Historical note: the Eniac was programmed as a bunch of autonomous
communicating processors, and everybody agreed that the programming was a
disaster. In some cases, the Eniac was slower than the mechanical Mark I
because for a given problem, the Mark I took 3 minutes to program and 10 to run
a problem, while the Eniac took 15 to program but only 2 seconds to run. Only
Von Neumann's idea of central control made it possible to write interestingly
large programs.)
I keep seeing multiprocessors announced with great fanfare and then hearing
nothing interesting afterward. Hmmn. The only place I can see where they
might be useful would be in a busy transaction system, e.g. an airline
reservation system, where having lots of processors for lots of transactions
could win relative to context switching one or two large processors, which is
what they actually do.
Finally, one interesting multiprocessor effort you might look at is the ELI
project at Yale, as described in the paper by Ficher et al. at the 1984
compiler construction conference. Their approach, though, is to have a large
parallel asymmetrical machine with one hugely wide instruction stream
controlling all of the parts, a far cry from the microprocessor jungles usually
promoted.
John Levine, Javelin Software, Cambridge MA 617-494-1400
{ decvax!cca | think | ihnp4 | cbosgd }!ima!johnl, Levine@YALE.ARPAbrooks@lll-crg.ARPA (Eugene D. Brooks III) (05/11/85)
> > Has anybody ever claimed there was any advantage to multiprocessors other than > price or (at the high end) constructability? The answer to this question is NO with one caviat. There are those who would say that a multiprocessor with caches on each processor is capable of superlinear performance. This is because the total amount of FAST memory in the system has increased and the result is a slight increase in performance due to the larger cache volume. The answer to this it to compare the the parallel system to a uniprocessor with the same cache volume. A parallel processor with the same aggregate performance, all other things equal, would never be preferrable to a uniprocessor unless your purpose is to study parallel algorithm development.
henry@utzoo.UUCP (Henry Spencer) (05/14/85)
Actually, in Computing Surveys some years ago there was mention of another
case where a multiprocessor got super-linear performance. "Multi" in that
case was 2, so it's not a striking example, but even so it was interesting.
The machine was a dual-processor IBM 360/67. The slightly-better-than-2
factor of performance was because some system overhead is not proportional
to the user load, and that overhead has to be incurred only once for both
processors. The 67 had an unusual i/o architecture that tended to direct
interrupts to the processor (if any) that wasn't busy at the time, which
helped.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henryatbowler@watmath.UUCP (Alan T. Bowler [SDG]) (05/17/85)
In article <5593@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >The 67 had an unusual i/o architecture that tended to direct >interrupts to the processor (if any) that wasn't busy at the time, which >helped. Actually I would not consider this at all unsual. Honeywell systems back to the old GE 635 have done this. Not all the software has taken advantage of the capability, but the architecture supported it. My general impression is that it is only IBM that has had conceptual fixations about having a "master" cpu in multiprocessing configurations. The lessons from the /67 were largely ignored for a long time.
ed@mtxinu.UUCP (Ed Gould) (06/03/85)
In article <5593@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >Actually, in Computing Surveys some years ago there was mention of another >case where a multiprocessor got super-linear performance. "Multi" in that >case was 2, so it's not a striking example, but even so it was interesting. >The machine was a dual-processor IBM 360/67. The slightly-better-than-2 >factor of performance was because some system overhead is not proportional >to the user load, and that overhead has to be incurred only once for both >processors. The 67 had an unusual i/o architecture that tended to direct >interrupts to the processor (if any) that wasn't busy at the time, which >helped. Probably true, but to some extent it's an apples-to-oranges comparison. The real reason that the /67 ran faster with two processors is really that the OS overhead was too large, and adding more user horsepower got a net improvement in throughput. I doubt that there were really more than 2 times as many instructions executed, total. IBM operating systems are noted for large overheads. One of theirs (OS/VS1 if memory serves correctly) ran faster under VM than it did native, i.e. the throughput went up by adding an *additional* layer of software between the OS and the hardware. (There is an explanation - we don't have a perpetual motion machine here: VS1's paging algorithm was *terrible*, so telling it that it had infinite amounts of real memory and letting VM do the pageing did the trick.) (This was true about 8 years ago when I had my few dealings with IBM systems. I don't think it's so any more.) -- Ed Gould mt Xinu, 2910 Seventh St., Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146