Xref: utzoo comp.arch:6904 comp.sys.next:373 Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!peregrine!elroy!ames!vsi1!wyse!mips!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch,comp.sys.next Subject: Re: RISC v. CISC (really comments on many postings: LONG) Message-ID: <7038@winchester.mips.COM> Date: 26 Oct 88 18:06:43 GMT Article-I.D.: winchest.7038 References: <156@gloom.UUCP> <6865@winchester.mips.COM> <468@oracle.UUCP> Reply-To: mash@winchester.UUCP (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 143 In article <468@oracle.UUCP> csimmons@oracle.UUCP (Charles Simmons) writes: >>>From: doug@edge.UUCP (Doug Pardee) >>>The incorrect assumption here is that you would want to build a mainframe >>>using RISC technology -- that RISC technology has anything to offer at >>>that price/cost level. >>Well, M/2000s act like 5860s, and we think next year's M/xxxx will >>make 5990s sweat some. Why wouldn't we want to build RISC-based mainframes? >>Lots of people do. In general, I agree 100% with Chuck: CPU performance doesn't necessarily imply I/O performance (which I've said numerous times), and if I'd not been in catchup mode, I would have said "sweat some on uniprocessor CPU performance". Actually, in terms of market conflict, as far as I can tell, despite managing to bump into lots of other people, Amdahl is one we don't, and probably never will. [Why? 1) Most people who buy from Amdahl have already chosen their architecture, based on existing applications, 2) They pick Amdahl over other PCMs or IBM for a variety of reasons, including cost/performance or smart features like the mulitple-domain thing, 3) Their customers tend to be very loyal, as they appear to be treated well. (These comments arise from having spoken at an Amdahl User's Group meeting not long ago and spending a lot of time talking to their customers.)] >A couple things. At Amdahl, people do think about things like building >a RISC based mainframe processor. The big problem that arises is in >guaranteeing object-code compatibility for old COBOL binaries that do >ugly things like use self-modifying code. But mainframe people are >definitely interested in RISC technology, and are working on thinking >up ways to take advantage of the technology. As noted elsewhere, it makes perfect sense, once you have some base for it, to keep pushing an architecture further. S/360 and it's descendants are clearly a fertile area for this. >John Mashey brings up a point that I've never had a satisfactory >answer to. If we assume that RISC-based manufacturers can build >machines that outperform mainframes, where will companies like Amdahl >make their money? When I asked this question around Amdahl, the >answer was "I/O bandwidth. I/O bandwidth!" This is a legitimate technical answer, as it certainly distinguishes things with mainframe-class CPU performance from real, large mainframes. (Actually, I think the other issues mentioned above are at least as important.) >To what extent would next year's M/xxxx (40 Mips?) processor really >make a 5990 sweat? I'll concede that on some programs, this processor- >to-come will be as fast as a 5990. But let's look at the kinds of >processing that are common on mainframes: database processing. >A 5990 can be equipped with 256 Megabytes of 55nanosecond static ram. >(That's its main memory, not its cache.) That kind of memory costs >a whole lot, and if you need that kind of memory (for your huge >database and 3000 users), it's going to cost, even on a RISC based >mainframe. Yep, absolutely. My guess is that it will be a while before people build RISC-based systems that can capture these sorts of applications: a) You do have to build memories with a lot of bandwidth. b) You have to build I/O, spend a lot of $ on reliability & serviceability. c) You have to move the applications. [IMS? CICS? hmmm.] d) You have to be a company of such size and nature that those folks will trust those applications to you....and some of those folks have only recently noticed that companies like DEC or Amdahl are substantial enough to consider :-) On the other hand, some mainframe cycles go towards engineering applications, or towards general time-sharing, and other less immediately "mission-critical" applications, and some of those we actually get a chance to fight for. (Actually, quite a few MIPS machines are used in multi-user database environments, but not in the same ones that Amdahls would be used in.) >The 5990 also has lots of I/O bandwidth. (Anyone want to help me >with the numbers here?) I believe that you can hook up something >like 32 4.5Megabyte (byte, not bit) per second channels to one of these >beasties. That kind of I/O bandwidth costs. (For comparison, >a diskless Sun has about 1.25 Megabytes of bandwidth [10 Megabit Ethernet].) >A diskful Sun probably doesn't have much more than 4 Megabytes. >So, a mainframe can do something like 30 times as much I/O as >a workstation...) Yes, I believe we won't have quite that bandwidth next year, although the I/O will be quite respectable at the price. Of course, we worry about the issue in general: CPU performance is going up so fast right now, it's clearly leaving cost-equivalent I/O behind. On the other hand, there is interesting work going on in the world towards, for example, farms of small disks, which can get some good bandwidth rather cheaply. >(People at Amdahl would also mention that when you build a mainframe, >is has to be highly reliable and extremely serviceable. Apparently, >there's a fair amount of hardware and money that go into increasing >the reliability and serviceability of a mainframe.) Yes. Note that here there is some edge for the RISCs, just because the basic hardware is simpler in the first place; it's less work to air-cool them, etc. The CPU+cache can be 1 board, etc. Again, this only applies to the CPU subsystem, but that's certainly one of the more stressful areas. >So, the basic claim that I want to make, and that I'd like to hear >counter-arguments to, is that if you build a RISC-based mainframe, >it's still going to cost $10,000,000. When you get to really large configurations, it's clear that very little of the money is in the CPU any more. On the other hand, sometimes you can trade CPU performance for some kinds of I/O gear (i.e., a small example would be having cheaper serial-i/o support because you can afford to have more CPU overhead per interrupt, becuase the CPU is faster). I'll have to think about the number: it will be a long time if ever before we build something that costs that much. >(Random thoughts... People at Amdahl are starting to worry that >the next generation of Amdahl mainframes might be able to support >64K concurrent processes, or at least enough processes to make >pid's wrap way to frequently. Has MIPS started worrying about >the problem of 16-bit pid's yet? Seems like MIPS might run into >trouble in 1990 or 1991...) (16-bit major/minor device numbers >are already too small for a 5890 [have you ever tried to configure >3000 terminal devices in an 8-bit field?] How much trouble is >MIPS having with this 16-bit limit?) We haven't done a lot in that direction, mainly because: a) It's more likely to get solved as part of the general UNIX evolution, I think. You guys have just run into it earlier than most people. b) We don't need to quite yet. Although we have some M/1000s that have 60-100 users on them, and M/2000s that will have more, I suspect we won't have 3000 for a while. Among other things, people get greedy, if the cycles are cheap. (We now have the spectacle of people having gotten used to having a 20-mips machine by themselves, and wanting it all of the time. Of course, we have people who'd barely be satisfied with Cray-YMPs on their desks, so that's probably not surprising.) Anyway, mainframe I/O is definitely in a different league right now. In fact, it might be instructive for the newsgroup for somebody to post a description of what a 5990 memory hierarchy looks like in more detail. This newsgroup argues more about microprocessors than mainframes. If you review computing history, you find that each wave [mainframe, mini, micro] has tended to repeat much of the evolution of the earlier waves. Now that VLSI micros are getting supermini & up performance, many of the same old issues will arise. -- -john mashey DISCLAIMER: UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086