Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!purdue!mentor.cc.purdue.edu!mace.cc.purdue.edu!mhm From: mhm@mace.cc.purdue.edu (Michael Marsh) Newsgroups: comp.sys.sequent Subject: Re:Questions about Pyramid/Sequent Keywords: multiprocessors,uniprocessors Message-ID: <2136@mace.cc.purdue.edu> Date: 5 Apr 89 20:55:45 GMT Distribution: na Organization: Purdue University Lines: 28 In comparing uniprocessors with multiprocessors, some years ago IBM did a study that showed that there are situations where a multiprocessor system has certain advantages over a monoprocessor that is "twice as fast". These are in the areas of interrupts and context switching. Large, fast machines tend to get a lot of their performance from techniques such as sophisticated caches, I/O processors, pipelining. large register sets, and the like. These mechanisms work most efficiently on large jobs using sophisticated compilers which take advantage of the architectural oddities of the particular machine. (Sound like the place to do batch processing? Yup!) Context switching and interrupt processing break these machines, and that is just what you get a lot of with 300 logged-on users. As you add more users to a large monoprocessor, a point will be reached where the system is spending all it's time context switching. A multiprocessor can handle more of this activity before degrading (if designed properly). A second advantage to the multiprocessor architecture is that an interrupt need "interrupt" only one processor, and in some implementations, (sequent's, for one) the interrupt is handled by the processor running the lowest priority process, leaving the more important processes to run uninterrupted. On a monoprocessor, even high priority jobs are prempted by interrupts. There is a psychological advantage to the multiprocessor in that the performance tends to be very uniform over a wide range of loads, whereas a uniprocessor, although faster, will start to slow down quicker, leaving the users with the feeling that they aren't getting all they could out of the machine. Disclaimer: These are the opinions of the author and not necessarily those of Purdue University or Sequent.