mash@mips.COM (John Mashey) (10/26/88)
In article <2005@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <6865@winchester.mips.COM>, mash@mips.COM (John Mashey) writes: >> [7] This is very confusing. Most RISCs use 3-address operations, i.e., >> reg3 = reg1 OP reg2. >> rather than just 2-address ops: >> reg1 = reg1 OP reg2 >I've been out of things for a while, but didn't RISCs use to use either >stack or load-store architecture? Or was that just RISC-1? RISCs are mostly load/store designs, but maybe I misread what you meant. Most RISCs use load/store designs, where a single load/store accesses 1 memory object, which generally can't cross page (or even naturally-aligned object) boundaries. Some of them allowed for simple indexed and/or auto-increment/decrement addressing. I don't know of any RISCs that have instructions that touch 3 addresses in memory, so I assume you were asking about the 3-operand forms (in registers), which are used by most RISCs. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> 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
csimmons@hqpyr1.oracle.UUCP (Charles Simmons) (10/26/88)
In article <6865@winchester.mips.COM> mash@winchester.UUCP (John Mashey) writes: >As you note, not-yet-announced. On the other hand, MIPS R3000s >do 42K Dhrystones, and they're already in real machines, and vendors >are quoting the CPUs at $10/mip, i.e., $200 for 25MHz parts. >Starting from scratch in 1984, and getting the first systems in mid-1986, >the high-performance VLSI RISC [i.e., MIPS as example] is: > 1986 5 MIPS > 1987 10 MIPS > 1988 20 MIPS The above two paragraphs aren't here for any good reason. I just liked them. (Remember that an Amdahl 5890 [the second fastest scaler processor in the world...:-] does on the order of 42 or 43K dhrystones.) >>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. 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. 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!" 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. 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...) (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.) 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. (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?) -- Chuck
mash@mips.COM (John Mashey) (10/27/88)
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: <generic disclaimer, I speak for me only, etc> 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
koopman@a.gp.cs.cmu.edu (Philip Koopman) (10/27/88)
In article <468@oracle.UUCP>, csimmons@hqpyr1.oracle.UUCP (Charles Simmons) writes: > In article <6865@winchester.mips.COM> mash@winchester.UUCP (John Mashey) writes: > >As you note, not-yet-announced. On the other hand, MIPS R3000s > >do 42K Dhrystones, and they're already in real machines, and vendors > >are quoting the CPUs at $10/mip, i.e., $200 for 25MHz parts. Hey, wait a minute. You can't just spec the price of the CPU itself, you need to include the cost of other required chips (like cache controllers, MMU's, or whatever) when you say how much the CPU costs. On some machines, you can't run without these extra components. Phil Koopman koopman@maxwell.ece.cmu.edu Arpanet 5551 Beacon St. Pittsburgh, PA 15217 PhD student at CMU and sometime consultant to Harris Semiconductor.
mash@mips.COM (John Mashey) (10/28/88)
In article <3404@pt.cs.cmu.edu> koopman@a.gp.cs.cmu.edu (Philip Koopman) writes: >In article <468@oracle.UUCP>, csimmons@hqpyr1.oracle.UUCP (Charles Simmons) writes: >> In article <6865@winchester.mips.COM> mash@winchester.UUCP (John Mashey) writes: >> >As you note, not-yet-announced. On the other hand, MIPS R3000s >> >do 42K Dhrystones, and they're already in real machines, and vendors >> >are quoting the CPUs at $10/mip, i.e., $200 for 25MHz parts. >Hey, wait a minute. You can't just spec the price of the CPU itself, >you need to include the cost of other required chips (like cache controllers, >MMU's, or whatever) when you say how much the CPU costs. On some machines, >you can't run without these extra components. 100% agree: I just don't know the rest of the numbers offhand. In our case, the mMU & cache control are on-chip; these days, you add an FPU (probably costs 1.5-2X the corresponding CPU), and SRAM (which is where most of the money is), plus some fairly cheap glue parts for the external memory interface. There was no intention to make people think the entire CPU core costs $10/mip, and if readers thought that, unthink it. I'd guess a whole CPU core (CPU + FPU + MMU + cache control + cache + external memory interface) currently costs about $70-$10/VUP for the kind of things you build in systems [less for embedded systems, especially as the 4Kx16 & similar-shaped SRAMs become more available.] -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> 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
mat@amdahl.uts.amdahl.com (Mike Taylor) (10/28/88)
In article <7038@winchester.mips.COM>, mash@mips.COM (John Mashey) writes: > 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. Your wish is my command. Each processor has a 64K byte instruction cache and a 64K byte operand cache, equipped with their own TLBs. Implemented in 16K chips, 2.8 ns. access (chips also have 1200 logic gates). From memory, I think it is organized as 128-byte lines, 4-way set associative, with about 15 cycles miss penalty. Main storage is up to 512 megabytes of 55ns. 256K SRAM, accessed as cache lines and interleaved. Below main storage, there is expanded storage and I/O. Expanded storage is up to 2GB of 1M DRAM, accessed as pages. I/O consists of up to 128 channels. 2 are byte-multiplexor channels, another 30 are either, and the remainder are only block-multiplexor channels. Block mux channels go up to 4.5 mB/sec. A typical configuration has about 5 GB/MIPS of DASD installed. So an average 5990-1400 at (say) 105 370 MVS MIPS would have about 500GB of DASD. Many of our customers have DASD farms in the terabyte league, however, plus tape, non-volatile electronic storage ("EDAS"), etc. -- Mike Taylor ...!{hplabs,amdcad,sun}!amdahl!mat [ This may not reflect my opinion, let alone anyone else's. ]