Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!granite!vajra!rwood From: rwood@vajra.uucp (Richard Wood) Newsgroups: comp.sys.pyramid,comp.sys.sequent Subject: Re: Questions about Pyramid/Sequent Summary: Check your premises Message-ID: <461@granite.dec.com> Date: 31 Mar 89 23:59:54 GMT References: <764@sactoh0.UUCP> <404@sequoia.UUCP> <63984@pyramid.pyramid.com> <13305@sequent.UUCP> <9903@polyslo.CalPoly.EDU> Sender: news@granite.dec.com Reply-To: rwood@dec.com or rwood@gatekeeper.dec.com (Richard Wood) Distribution: na Organization: Digital Equipment Corporation, U.S.Worksystems Lines: 131 Expires: Sender: Followup-To: Xref: utzoo comp.sys.pyramid:361 comp.sys.sequent:216 Cquenel@polyslo.CalPoly.EDU (48 more school days) writes: > > Suppose for the sake of argument you have a single processor > machine on one side and an 8 processor machine on the other side > with each processor exactly equal to 1/8 of the larger CPU. > Suppose the prices and total performances are equal. If your premises listed above were true, then much of your arguement below would be true as well. The significant error is to assume that a single CPU machine and a multiprocessor (with equivalent amounts of aggregate power) would have the same price. If all other design elements were pretty much the same, the multiprocessor should cost less. What are the arguments for the multiprocessor costing more? Significantly more complex design, with caches, probably a faster bus. On the other hand, the single CPU would have to be built with technology that is substantially more complex than the eight. For instance, today's '386 chips can be designed very easily to get 3 or so MIPS of power (more with a more expensive design). You can't get a '386 running 24 MIPS (eight times faster). Theoretically, you could, if you built it out of ECL or something. But that single CPU would no longer be a chip - it would now be a multichip design. The cost of designing that board will be substantially higher than the cost of designing the basic CPU subsystem in the multiprocessor. Even more importantly, the cost of manufacturing and servicing it would be very, very much higher. A final, but certainly not insignificant detail, is that the multiprocessor is going to get to market *A LOT* faster, due to the simpler overall design. Admiral Grace Hopper (inventor of Cobol) likens it to a farmer that suddenly needs to plow a field twice as big as his ox can handle. The single-CPU paradigm would have him buy an Ox that is genetically engineered to be twice as big, and twice as powerful. The multiprocessor paradigm would argue for simply getting a second ox. Any farmer could tell you which would be cheaper :-) The basic rationale is that it is cheaper to use off the shelf technologies as building blocks, instead of designing new processors for each and every generation. > My argument is that the mono-processor machine is more flexible > because any process can chew on the while machine whenever/however > it wants. No one will argue with you. A single source of cycles will always be able to allocate them with more flexibility. This actually follows directly from queuing theory. > I also claim that when the number of users is reasonably greater > than 8, then it will be difficult to tell which machine you're > using. I have equated number of users with number of active > processes here. It is possible for one user to have 5 active > processes (by "thinking parallel" :-) ) and it is possible to have 8 > users and have only 5 active processes. It actually happens (at least under Unix) even without "thinking parallel," although that does dramatically increase the flow. Sit down at a single user workstation sometime and do a "ps ax | wc -l". All the background stuff Unix does can take advantage of those "other" CPUs. (I.e., my workstation has 45 processes listed, and I'm hardly doing anything - true, most of those will wait hours before seeing action). A prime example is the inherent multiprocessing that is showing up in todays computing model. The window I'm editing in right now taps several different processes, including the editor, the terminal emulator (wish I had xrn...), the X-Server process, some NFS daemons on my local machine, and some on the server somewhere else in the building. > I seem to hear some advocates of multi-processors using the old > "gee it's neat when I've got all those processors to myself" > argument, but I don't think this is a valid argument for a > good general-purpose machine. > > If you are considering a working environment where there > are more processors than your average number of active > processes most of the time, then you would actually be better off > with a mono-processor. Think about it. Except, perhaps one should take into account the fact that the monprocessor is going to cost dramatically more, as explained above. There is some "clumsiness" about using a multiprocessor in a non-parallel processing environment, but the cost payoff can be dramatic. And > I have an 8 processor machine and I've spawned 7 processes. > I'm only using 7/8 of the machine. If I were on the mono-processor, > I'd be using 8/8 of the machine, and (!) all my tasks would > finish sooner. Even though I was sharing. > > It all boils down to this: > > The burden of proof is on the multi-processing > manufacturer. They have to prove they can offer > enough MORE bang/buck to counter act any difficulties > introduced by multiprocessing. The burden of proof should *always* be on the person trying to sell, regardless of what they're selling. There are tradeoffs in every decision. For this kind of purchasing problem, the questions are two: Do I have an environment that makes full use of multiple processors? If no... Is the presumably decreased cost of the multiprocessor worth the loss of flexibility in how I use the machine? > If you have a heavy number crunching grind-it-out program, > then you will have to "parallelize" it in order to take > advantage of any potential bang/buck advantage in a multi-CPU > system. There is another way that "heavy number crunching" programs can take advantage of a multiprocessor: concurrency. Run multiple versions of the same program simultaneously on different data sets. This assumes two things: first, that there are different data sets that need to be processed; if you only have the need to run one simulation at any time, for instance, then this wouldn't be the case. Second, it assumes that throughput is a reasonable substitute for response time. If having ten jobs done in ten minutes isn't as good as having one job done in one minute, than the thumper (to use a motorcycling term) is the proper tool. [A thumper is a single cylinder engine; the obvious analogy is left as an exercise for the reader] -- ---------------------------------------------------------------------------- Does it need saying that I'm not speaking as an official representative of DEC? =============================================================================== Richard Wood ! U. S. Worksystems, Palo Alto ! Digital Equipment Corporation