mwm@eris.UUCP (01/01/70)
In article <645@winchester.UUCP> mash@winchester.UUCP (John Mashey) writes: <In article <2628@ames.arpa> eugene@pioneer.UUCP (Eugene Miya N.) writes: <> <>While I am fully aware that VAXen are "popular" machines, the 780 is over <>ten years old. It makes me wonder: why not use the measure of ENIACs <>instead? [Don't try to answer that, better to strive for better forms <>of measurement] It's was one of Perlis' epigrams to have 100 ENIACS on a chip. < <This is a fair complaint from Gene. We use vax-mips (or VUPS) because: < 1) DEC's machines are calibrated this way, so that you can also < compare with 8700s, etc, if you're very careful. < 2) They do communicate information to many people, who at least < have a feel for the speed of an 11/780. Not that many people < have a feel for ENIACs. < 3) We at least have some! You forgot: 4) This group (Usenet, MIPS, or some such) is dealing with Unix, and most Unix wizards will be familiar with the 780. It hasn't been that long since, if you really wanted to run Unix, you either had a 780 (no 750 back then) or a PDP-11, and the world was shifting to VAXen. Nuts, I even remember Bill Joy telling me at a Usenix that "VAXen are where everything interesting is going to be happening" ('twas true, 'twas true). Since most sites worrying about mini/supermini-sized Unix boxes will have someone around who has a feel for what a 780 is/does, they make a good benchmark standard. This will change with time, but by then they'll be entrenched. I can see it now: Wizard: "This machine is 1e23 11/780 mips." Wwtb: "What's an 11/780." Wizard: "Dunno. We've always used them to measure machines, though." Of course, as someone who deals with large timeshareing Unix boxes, I'll be happy to tell you why a Sun 3/xx at 2 or 3 11/780 mips won't replace a real 780..... <mike -- ICUROK2C, ICUROK2. Mike Meyer ICUROK2C, ICWR2. mwm@berkeley.edu URAQT, I WANT U2. ucbvax!mwm OO2EZ, I WANT U2. mwm@ucbjade.BITNET
alan@pdn.UUCP (Alan Lovejoy) (01/01/70)
In article <649@winchester.UUCP> mash@winchester.UUCP (John Mashey) writes: >Again, this is not to denigrate cycles/instruction as something architects >use: I just have trouble when people start throwing the numbers around >with insufficient precision. I've even seen things published by people >comparing CPI of their systems and our systems, where we still cannot figure >out how they derived the numbers for our systems [or their systems, either]. >I just have this strange fondness for numbers where I can know where they >come from, and where I can measure them without magic. Of course, the more accurate the data, the better. However, in the real world... >>[I offer to mail John Motorola's Benchmark Report] >Yes: please. It would be useful to understand what they're saying. Done, provided there is a Snail Mail address somewhere in your article I can use :-). >>>[I assert that the native Cycles Per Instruction ratio is better than a normalized CPI] >I must be missing something. What is wrong with cycles / (unit of work)? >If two CPUs (34010?) have the same CPI, but differ in cycles/(unit of work), The 34010 is Texas Instruments "Graphics Processor"--although it could be used as a "general purpose" CPU (whatever that is :-) ). >then it must be that one of them is executing a lot more instructions on >a given benchmark. This was the original anti-RISC argument: "yes, the Aha! "on a given benchmark"! Precisely! Normalizing to "units of work" NECESSARILY involves using a (set of) "given benchmark(s)". It is a virtual certainty that any set of benchmarks you choose skews the measurement of work so that some CPU's will either suffer or benefit to an extreme degree in their percieved performance using normalized instructions to measure work accomplished. Eventually, of course, one must decide on a benchmark suite, but that "binding" should be delayed for as long as possible, so that the performance numbers are not "skewed" before they have to be. >>Obviously, it is necessary to find the optimum balance between these to >>conflicting constraints. I would like to see a mathematical proof >>or theory that could demonstrate or discover just what that balance is. >>Without it, machine designers are little more that artists, not >>engineers. >I doubt there is a closed mathematical solution to this problem, (if there were, >the optimal machines would be designed already!), but there is an iterative >process that has been used at various places, and is by now pretty >well-known: >>[John describes a process of tweaking a simulated machine's architecture until the numbers look good] There is, then, no way to absolutely determine what instructions should be included and which ones left out. Trial and error methods are of course useful when nothing better is available, but I have to question whether this gives people the right to make general statements about what sort of architecture/instruction set represents the optimum that can be achieved. Experimentation of the sort that John describes to discover a better instruction set than one started out with should be also aimed at discovering the general principles by which such things should be designed, with an eye towards eventually deriving a comprehensive and predictive theory. Failing that, one can never know that one is not missing something important and/or following a dead-end path. I, for one, would rather not change CPU architectures as often as I buy new clothes, especially when there is no guarantee that something ten times better won't be announced tomorrow. --alan@pdn
mjl@tropix.UUCP (Mike Lutz) (01/01/70)
In article <649@winchester.UUCP> mash@winchester.UUCP (John Mashey) writes: >In article <1221@pdn.UUCP> alan@pdn.UUCP (0000-Alan Lovejoy) writes: >>Obviously, it is necessary to find the optimum balance between these to >>conflicting constraints. I would like to see a mathematical proof >>or theory that could demonstrate or discover just what that balance is. >>Without it, machine designers are little more that artists, not >>engineers. > >I doubt there is a closed mathematical solution to this problem, >(if there were, the optimal machines would be designed already!), >but there is an iterative process that has been used at various places, >and is by now pretty well-known: ... description of the method follows ... John hit the nail on the head. Most engineers I know, whether working with hardware or software, do not deal with problems having closed mathematical solutions. Successful engineering requires judgement, insight, creativity, and even a sense of the elegant and aesthetic. What separates engineering from pure art, however, is that these qualities are based on rational, scientific models of the system under investigation, and such models are in turn informed by mathematics, natural sciences, and in many cases, by "soft sciences" such as psychology. Indeed, if a problem has a closed mathematical solution, then who needs engineers at all? Crank the numbers through a the formula, and voila! the optimal answer appears! Those interested in pursuing the view of engineering put forth in this note should read Florman's "The Existential Pleasures of Engineering." Mike L(a,b
mash@mips.UUCP (John Mashey) (08/25/87)
Chuck Simmons (amdahl!chuck) writes: >In article <1588@apple.UUCP> bcase@apple.UUCP (Brian Case) writes: >> The >>MIPS Co. processor, SUN 4 processor, the Acorn RISC machine processor, >>the Am29000 processor, etc. have, at least, for some problems, performance >>equal to or greater than multimillion dollar machines, at prices orders >>of magnitude lower. > >Anyone have an example of an application that runs faster on a MIPS, >Sun, Acorn, or AMD machine than it does on either a 5890 or a Cray 2? I suspect Brian was being a little enthusiastic, however: James Woods' compress benchmark: u+s user sys Cray 2 1.86 1.80 0.06 Mips M/1000 1.6- 1.4 0.2- empty system, sys = .1 or .2 Amdahl 5890-190 0.54 0.51 0.03 (== half of a model 5890-300 CPU) Of course, that's cheating, beating up a Cray-2 with character-pushing! Then, there's the Doduc benchmark (FORTRAN Monte Carlo): Perf Rel to 11/780 5.7 Amdahl 470 V8, VM/UTS 7.0 IBM 3081-G, F4H ext, opt=2 8.4 MIPS M/1000, f77 -O3, 1.21, UMIPS-BSD 2.01, runs 218 secs 18.3 Amdahl 5860 41.6 Cray X/MP [for perspective: we have a way to go yet!] On things like Hspice, we think an M/1000 is only about .25-.3X of an IBM 3090. In general, I'd suggest that the raw scalar CPU (integer/FP) speed of fast RISC micros is in the .25-.35X range relative to the big iron, at best. It will be two years before CMOS micros can match what's there now in overall scalar computational performance. (But that's not bad. There is about 100X difference in cost). Chuck: how about enlightening us all by posting the current Amdahl high-end machines' salient characteristics? cycle time? cache-sizes? mips-ratings? number of CPUs? The numbering has gone crazy, and it's hard to know what's faster than what up there. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!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.amdahl.com (Mike Taylor) (08/26/87)
In article <622@winchester.UUCP>, mash@mips.UUCP (John Mashey) writes: > > Chuck: how about enlightening us all by posting the current Amdahl > high-end machines' salient characteristics? cycle time? > cache-sizes? mips-ratings? number of CPUs? The numbering has gone > crazy, and it's hard to know what's faster than what up there. > -- I know you asked Chuck, but since I've recently done some performance studies on the UTS environment, I'll put two cents in. The 5890 family is the newest product line from Amdahl, following the 5860 and 470 families. UTS/580 is supported on 5860 and 5890 models in native mode. Model CPUs Cycle "MIPS" (ns.) MVS Commercial UTS typical 5890-180E 1 15 18 27e 5890-190E 1 15 22 33 5890-200E 2 15 31 46e 5890-300E 2 15 40 60e 5890-400E 3 15 60 90e 5890-600E 4 15 75 112e e = estimated ( all actual benchmarks have been done on 5890-190 or a UP domain of a 5890-300 which is pretty much the same ). I assumed that normal ratios would hold good off the baseline model. The -180 is a degrade of the -190, and the -200 is a degrade of the -300. MVS Commercial MIPS are approximate actual instruction execution rates for our "typical" MVS commercial workload. UTS MIPS are relative performance (throughput capacity) to the VAX-11/780 arbitrarily defined as 1 MIPS, not measured instruction execution rate. We will be doing actual IER measurements soon. The primary technology is 350 ps. 400 gate ECL arrays, with a few more exotic chips. All machines are air cooled. -- Mike Taylor ...!{ihnp4,hplabs,amd,sun}!amdahl!mat [ This may not reflect my opinion, let alone anyone else's. ]
mash@mips.UUCP (08/27/87)
In article <12953@amdahl.amdahl.com> mat@amdahl.amdahl.com (Mike Taylor) writes: >Model CPUs Cycle "MIPS" > (ns.) MVS Commercial UTS typical >5890-190E 1 15 22 33 >..UTS MIPS are relative performance (throughput capacity) to the VAX-11/780 >arbitrarily defined as 1 MIPS, not measured instruction execution rate. Thanx for the posting! This yields the amusing thought that the 5890 acts like a RISC, according to the (simplistic) MHz/mips ratio: mips MHz MHz/mips CPU / System 2 16.7 8.3 68020 (in Sun-3/160) 5 33 6.6 Fairchild Clipper 4 25 6.2 68020 (in Sun-3/260; caches help) 6 22.2 3.7 VAX 8700 33 66 2.0 Amdahl 5890-190E 10 15 1.5 MIPS M/1000 This is a good illustration of the well-understood fact that you can keep the cycles/mips ratio pretty low, even for a clearly non-RISC architecture. The cost is enough iron to give enough parallelism to permit heavy pipelining. Are the MVS Commercial mips equivalent to the way IBM measures mips? -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!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
pf@diab.UUCP (08/27/87)
With some interest i have watched the small "war" between as You call it "micros" and "Big Iron". If one looks back and just think about the past: 1. "Yesterday" Big Iron was what supermicros are today. Yes the price per "Mips (hate that term :-))" is much lower then many years ago. But look what You can get for the same ammount of monney that You paid for the Big Iron "Yesterday" today. In a few year there will bee so called 10,20 and even 30 mips micro chips, that will be "very cheap". But only because one type of processors improves (micros), that does not mean that everything else stops. Just compare "solid state memorys" vs "disk storage". And that's only one example. 2. One other point that is interesting (my oppinion) is how much easier it has become for people to access computers. Compare "The Dark Ages" where computer installations was so called "Closed Shops" whith the PC world today. And by the way, just look how much power there is in an $995. PC compared to the "$n*10e6" yesterday mainframes. I don't think it's real fair to compare the raw power of a mainframe system with a microprocessor chip, and then say that micros are so and so much cheaper. Yes, they are cheaper if you only look at raw power, but i think it must be seen in a bigger perspective (e.g. system level). Well, the computer evolution rolls on and will probably not stop in our age. New types of computers will show up (maybe with some new fancy name) having completley different architectures than we are used to.
mat@amdahl.amdahl.com (Mike Taylor) (08/27/87)
In article <630@winchester.UUCP>, mash@mips.UUCP (John Mashey) writes: > In article <12953@amdahl.amdahl.com> mat@amdahl.amdahl.com (Mike Taylor) writes: > Thanx for the posting! This yields the amusing thought that the > 5890 acts like a RISC, according to the (simplistic) MHz/mips ratio: > The 5890 is a RISC with a bag on the side in some sense ... heavily optimized to the frequent instructions (Load, store, branch.. you know) > Are the MVS Commercial mips equivalent to the way IBM measures mips? Yes, they are intended to be. BTW, MIPS ratings are unofficial in the sense that we only announce relative performance to our other processors. -- Mike Taylor ...!{ihnp4,hplabs,amd,sun}!amdahl!mat [ This may not reflect my opinion, let alone anyone else's. ]
alan@pdn.UUCP (Alan Lovejoy) (08/29/87)
In article <630@winchester.UUCP> mash@winchester.UUCP (John Mashey) writes: >Thanx for the posting! This yields the amusing thought that the >5890 acts like a RISC, according to the (simplistic) MHz/mips ratio: > >mips MHz MHz/mips CPU / System >2 16.7 8.3 68020 (in Sun-3/160) ...note that Sun's MIPS figures are converted to VAX equivalent, and the '2' figure widely quoted represents the equivalent VAX MIPS; the 'native' MIPS figure is about 3... >5 33 6.6 Fairchild Clipper >4 25 6.2 68020 (in Sun-3/260; caches help) ...see the comment above for the Sun-3/160... >6 22.2 3.7 VAX 8700 >33 66 2.0 Amdahl 5890-190E >10 15 1.5 MIPS M/1000 > >This is a good illustration of the well-understood fact that >you can keep the cycles/mips ratio pretty low, even for a clearly >non-RISC architecture. The cost is enough iron to give enough >parallelism to permit heavy pipelining. > mips* MHz MHz/mips CPU/ System 6 16.7 2.78 68030 4 20 5.0 80386 (assumes native mode 32-bit code) 10 30 3.0 32532 *based on manufacturers' claims It cannot be denied that a low Mhz/mips ratio is a good thing, and as the numbers above demonstrate, the major players appear to be steadily reducing this statistic for their products. However, as Motorola pointed out in one of their benchmark reports, a CPU can have fewer MIPS but higher 'performance'. The statistic that REALLY is important is work-accomplished/time. That is admittedly much harder to measure. It is amusing to see the hardware people champion "simplicity" of design at the expense of software complexity, while software people clamor for "simplicity" of design at the expense of hardware complexity (for example, Niklaus Wirth). Shifting complexity around between hardware and software is just irresponisble sleight of hand unless you can prove, on a case-by-case basis, that a given function is more efficiently handled either in the hardware or the software. --alan@pdn please ignore this attempt to prevent the new/old ratio checker from sending my article to nya-nya land
mash@mips.UUCP (John Mashey) (08/30/87)
In article <1202@pdn.UUCP> alan@pdn.UUCP (0000-Alan Lovejoy) writes: >In article <630@winchester.UUCP> mash@winchester.UUCP (John Mashey) writes: >>mips MHz MHz/mips CPU / System >>2 16.7 8.3 68020 (in Sun-3/160) >...note that Sun's MIPS figures are converted to VAX equivalent, >and the '2' figure widely quoted represents the equivalent VAX MIPS; >the 'native' MIPS figure is about 3... Oops. Having included "using definition 1 mips = VAX 11/780, 4.3BSD" in this newsgroup dozens of times, I forgot to do it this time. Note that on every benchmark we do, we measure the performance on the fastest VAX 11/780 that is relevant to the benchmark and that we can lay our hands on, call that 1, and then comptue any ratios relative to that, specifiyign which one it was. I'm curious: how does someone (other than a person with a complete architectural simulator, or ultra-precise hardware monitors), ever know what the `native mips' rating is, at least one machines that have caches, TLBs, etc? >>5 33 6.6 Fairchild Clipper >>4 25 6.2 68020 (in Sun-3/260; caches help) >...see the comment above for the Sun-3/160... >>6 22.2 3.7 VAX 8700 >>33 66 2.0 Amdahl 5890-190E >>10 15 1.5 MIPS M/1000 > mips* MHz MHz/mips CPU/ System > 6 16.7 2.78 68030 > 4 20 5.0 80386 (assumes native mode 32-bit code) > 10 30 3.0 32532 >*based on manufacturers' claims (Are these the same kinds of mips as the scale I was using? If so, how many people out there believe that a 16.7MHz 030 will be 3X faster than a Sun3/160, or 1.5X a Sun3/260?) >It cannot be denied that a low Mhz/mips ratio is a good thing, and >as the numbers above demonstrate, the major players appear to be >steadily reducing this statistic for their products. >However, as Motorola pointed out in one of their benchmark reports, >a CPU can have fewer MIPS but higher 'performance'. The statistic >that REALLY is important is work-accomplished/time. That is admittedly >much harder to measure. (Could you give a better citation for these reports?) I think we all agree that what is important is real work, not how many actual instructions are being executed. That's why I always use relative performance numbers, as slippery as they are, since "peak mips", "sustained mips", "native mips" really just don't mean much to most people. (Recall that Moto has advertised that a 25MHz 68020 does "12.5 burst mips" and "5 sustained mips".) Most people know that relative performance over a range of benchmarks is seldom a single number, but a range. For example, a "6-mips" VAX 8700 is anywhere from 3X to nearly 8X faster than an 11/780, even using the same software and OS. Thus, at best, the "N-vax-mips" number is a gross approximation to saying "if you run a lot of real programs, some will run faster, and some will run slower, but N is typical, and not too far off the mean (arithmetic, geometric, harmonic, or otherwise). Work-accomplished/time is NOT harder to measure, and the numbers used above were approximations of doing all the detailed work. Here is a table for 3 machines, in same form as the earlier articles: mips MHz MHz/mips CPU / System 1 5 5 VAX 11/780, 4.3BSD 2 16.7 8.3 68020 (in Sun-3/160), SunOS 3.2 5 8 1.6 MIPS M/500, UMIPS-BSD 2.0beta, 1.10 compilers Here is the table of timings for an nroff benchmark (MIPS Performance Brief, April 1987,p.6), which are then normalized to 'vax-mips', and the table above recomputed: Time mips MHz MHz/mips CPU / System 18.8 1 5 5 VAX 11/780, 4.3BSD 9.0 2.1 16.7 7.95 68020 (in Sun3/160) 3.3 5.7 8 1.4 MIPS M/500 To do a complete analysis, one should take hundreds of real benchmarks and do this, but this is sufficiently typical to be useful. (Note that the numbers aren't a lot different for MHz/mips). This approach has pluses and minuses, compared with real cycles/instruction: + mips (this way) gives you some feal for delivered relative performance + it is easy for anybody to compute, unlike cycles/(native instruction) - the base is a moving target that changes with compilers > >It is amusing to see the hardware people champion "simplicity" of design >at the expense of software complexity, while software people clamor >for "simplicity" of design at the expense of hardware complexity >(for example, Niklaus Wirth). Shifting complexity around between >hardware and software is just irresponisble sleight of hand unless >you can prove, on a case-by-case basis, that a given function >is more efficiently handled either in the hardware or the software. I think there's a complaint here, but I'm not exactly sure what it is, or who it's aimed at. If the first part was aimed at RISC fans, it does seem a little misplaced, since many of the most vocal RISC advocates are software people! More specificity would help on the rest: I'd be glad to answer the comments if I knew what they meant. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!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
eugene@pioneer.UUCP (08/31/87)
In article <640@winchester.UUCP> mash@winchester.UUCP (John Mashey) writes: >Oops. Having included "using definition 1 mips = VAX 11/780, 4.3BSD" >in this newsgroup dozens of times, I forgot to do it this time. >Note that on every benchmark we do, we measure the performance on >the fastest VAX 11/780 that is relevant to the benchmark and that we >can lay our hands on, call that 1, and then comptue any ratios >relative to that, specifiyign which one it was. While I am fully aware that VAXen are "popular" machines, the 780 is over ten years old. It makes me wonder: why not use the measure of ENIACs instead? [Don't try to answer that, better to strive for better forms of measurement] It's was one of Perlis' epigrams to have 100 ENIACS on a chip. Back to writing. From the Rock of Ages Home for Retired Hackers: --eugene miya NASA Ames Research Center eugene@ames-aurora.ARPA "You trust the `reply' command with all those different mailers out there?" "Send mail, avoid follow-ups. If enough, I'll summarize." {hplabs,hao,ihnp4,decwrl,allegra,tektronix,menlo70}!ames!aurora!eugene
henry@utzoo.UUCP (Henry Spencer) (08/31/87)
> It is amusing to see the hardware people champion "simplicity" of design > at the expense of software complexity, while software people clamor > for "simplicity" of design at the expense of hardware complexity > (for example, Niklaus Wirth).... Many of the software people are among those clamoring for simplicity of hardware design, mostly because the hardware designers have such a history of getting things wrong when they try to be clever. -- "There's a lot more to do in space | Henry Spencer @ U of Toronto Zoology than sending people to Mars." --Bova | {allegra,ihnp4,decvax,utai}!utzoo!henry
mash@mips.UUCP (John Mashey) (09/01/87)
In article <2628@ames.arpa> eugene@pioneer.UUCP (Eugene Miya N.) writes: > >While I am fully aware that VAXen are "popular" machines, the 780 is over >ten years old. It makes me wonder: why not use the measure of ENIACs >instead? [Don't try to answer that, better to strive for better forms >of measurement] It's was one of Perlis' epigrams to have 100 ENIACS on a chip. This is a fair complaint from Gene. We use vax-mips (or VUPS) because: 1) DEC's machines are calibrated this way, so that you can also compare with 8700s, etc, if you're very careful. 2) They do communicate information to many people, who at least have a feel for the speed of an 11/780. Not that many people have a feel for ENIACs. 3) We at least have some! As Gene knows well, we usually try to get as many numbers from as many machines as possible for our Performance Briefs. We're starting to do more comparisons relative to Crays and Amdahls; it's just a lot harder to get numbers, and I asked for a Cray for benchmarking, but my boss wouldn't buy it for me :-) As Steve Wallach (of Convex) said at last UNIX Expo (loosely paraphrased): there's VAX-relative benchmarking, and there's serious macho benchmarking (fractions of CRAYs). -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!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
john@geac.UUCP (John Henshaw) (09/01/87)
In article <8524@utzoo.UUCP>, henry@utzoo.UUCP (Henry Spencer) writes: > > It is amusing to see the hardware people champion "simplicity" of design > > at the expense of software complexity, while software people clamor > > for "simplicity" of design at the expense of hardware complexity > > (for example, Niklaus Wirth).... > > Many of the software people are among those clamoring for simplicity of > hardware design, mostly because the hardware designers have such a history > of getting things wrong when they try to be clever. Software designers aren't the bee's knees either. The only big difference is in the "medium of cleverness". However, I think that reasons for this bias run deeper than that... In particular, software is more "malleable" than hardware and therefore in many ways, far easier to work with than hardware. This of course means that it provides plenty of opportunity to make mistakes, but I believe that the cost of repairing those software mistakes is *usually* lower than that of hardware. Along the same lines, I note that an algorithm can't "break", whereas hardware can and (if we wait long enough,) will. Once the software is "right" (working correctly), we then need reliable hardware. Simple hardware tends to be more reliable. -john- -- John Henshaw, (mnetor, yetti, utgpu !geac!john) Geac Computers Ltd. "My back to the wall, Markham, Ontario a victim of laughing chance..."
alan@pdn.UUCP (09/01/87)
In article <640@winchester.UUCP> mash@winchester.UUCP (John Mashey) writes: >I'm curious: how does someone (other than a person with a complete >architectural simulator, or ultra-precise hardware monitors), ever know >what the `native mips' rating is, at least one machines that have >caches, TLBs, etc? Without access to the proper equipment, you either believe the reports of those who do, or make approximations based on timing the execution of a known number of instructions (dynamically counted). Wasn't that obvious? >>[table of CPU/MIPS/MHz supplied by me] >(Are these the same kinds of mips as the scale I was using? >If so, how many people out there believe that a 16.7MHz 030 will be >3X faster than a Sun3/160, or 1.5X a Sun3/260?) The MIPS numbers were for native instructions/second executing "average" code. In other words, the 68030 is at least twice as fast as a 68020 at the same MHz (average speed). >>[reference to Motorola report which states that lower MIPS does not >>necessarily mean lower performance--in fact, the reverse may be true] >(Could you give a better citation for these reports?) I think we all Sorry, I don't have one handy. If you're really interested, I can mail you one. >agree that what is important is real work, not how many actual instructions >are being executed. That's why I always use relative performance >numbers, as slippery as they are, since "peak mips", "sustained mips", >"native mips" really just don't mean much to most people. Using "normalized" MIPS I have no problem with--except for a MHz/MIPS ratio. Using normalized MIPS in such a ratio is ridiculous, unless you want to "normalize" the MHz as well--clearly a bizarre idea. The whole point of the ratio is to see average cycles per instruction, not average cycles per unit-of-work, since a 6888x and a 34010 can have the same number of cycles per instruction, but very disproportionate cycles per unit-of-work DEPENDING ON THE TASK BEING MEASURED. Once you have calculated the cycles/instruction ratio, then you can calculate a more meaningful work/instruction ratio from it. >>It is amusing to see the hardware people champion "simplicity" of design >>at the expense of software complexity, while software people clamor >>for "simplicity" of design at the expense of hardware complexity >>(for example, Niklaus Wirth). Shifting complexity around between >>hardware and software is just irresponisble sleight of hand unless >>you can prove, on a case-by-case basis, that a given function >>is more efficiently handled either in the hardware or the software. >I think there's a complaint here, but I'm not exactly sure what it is, >or who it's aimed at. If the first part was aimed at RISC fans, it >does seem a little misplaced, since many of the most vocal RISC >advocates are software people! More specificity would help on the >rest: I'd be glad to answer the comments if I knew what they meant. >-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> There is a fixed cost associated with executing an instruction that has nothing to do with how 'simple' or 'complex' it is (the number of bits needed to encode the instruction IS important, however). This argues that instructions should perform as much work as possible. Instructions that perform a lot of work may do more work than was needed, wasting machine resources. This argues that instructions should do as little work as possible. Obviously, it is necessary to find the optimum balance between these to conflicting constraints. I would like to see a mathematical proof or theory that could demonstrate or discover just what that balance is. Without it, machine designers are little more that artists, not engineers. --Alan@pdn
mat@amdahl.UUCP (09/01/87)
In article <4949@jade.BERKELEY.EDU>, mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) writes: > Of course, as someone who deals with large timeshareing Unix boxes, > I'll be happy to tell you why a Sun 3/xx at 2 or 3 11/780 mips won't > replace a real 780..... > I think that would be an interesting discussion. I, for one, would be interested in your views. Perhaps you might kick things off.... -- Mike Taylor ...!{ihnp4,hplabs,amd,sun}!amdahl!mat [ This may not reflect my opinion, let alone anyone else's. ]
jones@fortune.UUCP (09/02/87)
In article <8524@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> It is amusing to see the hardware people champion "simplicity" of design >> at the expense of software complexity, while software people clamor >> for "simplicity" of design at the expense of hardware complexity >> (for example, Niklaus Wirth).... > >Many of the software people are among those clamoring for simplicity of >hardware design, mostly because the hardware designers have such a history >of getting things wrong when they try to be clever. Thanx, Henry, for inspiring me. Jones's Observation on Simplicity: The only thing more complex than clever hardware is clever software. Dan Jones
henry@utzoo.UUCP (Henry Spencer) (09/02/87)
> 2. One other point that is interesting (my oppinion) is how > much easier it has become for people to access computers. > Compare "The Dark Ages" where computer installations was > so called "Closed Shops" whith the PC world today... Actually, this is not "easier access" but "easy access at a lower price". The micro people have rediscovered what some of us had with minicomputers 15 years ago, and some of the mainframe people had still earlier. Walking up to the computer, sitting down, and starting work has always been possible, if your employer was willing to pay enough. -- "There's a lot more to do in space | Henry Spencer @ U of Toronto Zoology than sending people to Mars." --Bova | {allegra,ihnp4,decvax,utai}!utzoo!henry
mash@mips.UUCP (09/02/87)
In article <1221@pdn.UUCP> alan@pdn.UUCP (0000-Alan Lovejoy) writes: >In article <640@winchester.UUCP> mash@winchester.UUCP (John Mashey) writes: >>I'm curious: how does someone (other than a person with a complete >>architectural simulator, or ultra-precise hardware monitors), ever know >>what the `native mips' rating is, at least one machines that have >>caches, TLBs, etc? >Without access to the proper equipment, you either believe the reports >of those who do, or make approximations based on timing the execution of >a known number of instructions (dynamically counted). Wasn't that >obvious? 1) Taking anything on faith in computer performance measurement: exciting. 2) Approximations based on timing the execution of a known number of instructions: a) In any machine except a pure 1-cycle, 1-instructtion RISC with no cache or TLB, it is HARD to get this to mean much, in general. b) You can write programs that do things like a million adds, and count the number of instructions in the loop. This doesn't tell you much about real programs. c) You can run real programs, time them, and then go back and count the instructions. This gets back to having a full-bore architectural simulator. Again, this is not to denigrate cycles/instruction as something architects use: I just have trouble when people start throwing the numbers around with insufficient precision. I've even seen things published by people comparing CPI of their systems and our systems, where we still cannot figure out how they derived the numbers for our systems [or their systems, either]. I just have this strange fondness for numbers where I can know where they come from, and where I can measure them without magic. >>(Are these the same kinds of mips as the scale I was using? >>If so, how many people out there believe that a 16.7MHz 030 will be >>3X faster than a Sun3/160, or 1.5X a Sun3/260?) >The MIPS numbers were for native instructions/second executing >"average" code. In other words, the 68030 is at least twice as fast >as a 68020 at the same MHz (average speed). >>>[reference to Motorola report which states that lower MIPS does not >>>necessarily mean lower performance--in fact, the reverse may be true] >>(Could you give a better citation for these reports?) I think we all >Sorry, I don't have one handy. If you're really interested, I can mail >you one. Yes: please. It would be useful to understand what they're saying. > >>agree that what is important is real work, not how many actual instructions >>are being executed. That's why I always use relative performance >>numbers, as slippery as they are, since "peak mips", "sustained mips", >>"native mips" really just don't mean much to most people. >Using "normalized" MIPS I have no problem with--except for a MHz/MIPS >ratio. Using normalized MIPS in such a ratio is ridiculous, unless >you want to "normalize" the MHz as well--clearly a bizarre idea. >The whole point of the ratio is to see average cycles per instruction, >not average cycles per unit-of-work, since a 6888x and a 34010 can have >the same number of cycles per instruction, but very disproportionate >cycles per unit-of-work DEPENDING ON THE TASK BEING MEASURED. Once >you have calculated the cycles/instruction ratio, then you can calculate >a more meaningful work/instruction ratio from it. I must be missing something. What is wrong with cycles / (unit of work)? If two CPUs (34010?) have the same CPI, but differ in cycles/(unit of work), then it must be that one of them is executing a lot more instructions on a given benchmark. This was the original anti-RISC argument: "yes, the instructions go faster, but you have to do a lot more of them, so the actual work done is the same, or little more." One of the reasons we've gotten away from quoting CPI numbers was the continual objections of people to the kind of analysis that says: performance = (# instrs) / (cycle-time * CPI) with the claim that given a constant cycle-time (dependent on technology), that RISCs a) radically reduced CPI, while b) only moderately increasing (# instructions). I believe that is basically true, more-or-less, given that you throw in "at comparable hardware cost", since you can make CISCs go fast by throwing lots of hardware at it. THE PROBLEM IS THAT YOU COULD GET CONVINCING NUMBERS FOR YOUR OWN MACHINES FOR INSTRUCTIONS and CPI, but NOT for anybody else's, at least, you couldn't get numbers that people would believe. > >>It is amusing to see the hardware people champion "simplicity" of design > >>at the expense of software complexity, while software people clamor > >>for "simplicity" of design at the expense of hardware complexity > >>(for example, Niklaus Wirth). Shifting complexity around between > >>hardware and software is just irresponisble sleight of hand unless > >>you can prove, on a case-by-case basis, that a given function > >>is more efficiently handled either in the hardware or the software. > > >I think there's a complaint here, but I'm not exactly sure what it is, > >or who it's aimed at. If the first part was aimed at RISC fans, it > >does seem a little misplaced, since many of the most vocal RISC > >advocates are software people! More specificity would help on the > >rest: I'd be glad to answer the comments if I knew what they meant. > >>-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> > >There is a fixed cost associated with executing an instruction that has >nothing to do with how 'simple' or 'complex' it is (the number of bits >needed to encode the instruction IS important, however). This argues >that instructions should perform as much work as possible. >Instructions that perform a lot of work may do more work than was >needed, wasting machine resources. This argues that instructions should >do as little work as possible. >Obviously, it is necessary to find the optimum balance between these to >conflicting constraints. I would like to see a mathematical proof >or theory that could demonstrate or discover just what that balance is. >Without it, machine designers are little more that artists, not >engineers. I doubt there is a closed mathematical solution to this problem, (if there were, the optimal machines would be designed already!), but there is an iterative process that has been used at various places, and is by now pretty well-known: a) Start with a set of benchmarks that you think are relevant to the computers you want to build. b) Define a baseline architecture. c) Create compilers that can generate code for the baseline. d) Create a simulator that can execute code for the architecture and generate all the statistics you need to determine performance. e) Now, iterate steps b-d by tweaking the architecture and fixing the others. - You might add an instruction, whose use lets you decrease the path-length, and it might be free, or it might increase the machine's cycle time, in which case you have to analyze the results carefully. - You might delete an instruction, increasing the path length, but perhaps decreasing the cycle time. - It turns out, both HP and we finally used a rule like "If you can't prove an instruction is worth 1% in overall performance, don't add it." f) Sooner or later, you get tired, or you've converged as best you can, or your venture capitalists would like a product sometime, and you go build it. Of course, in reality, you often have to do this under time pressure, and your results are no better than your set of benchmarks, plus the level of approximation offered by your compilers and simulators. Picking the worng benchmarks can be catastrophically bad if they make you believe you can leave something out that shouldn't be. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!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
rick@seismo.CSS.GOV (Rick Adams) (09/02/87)
Well, to start with I've got a Vax 11/780 with 7 6250 bpi 125 ips tape drives on it. It performs adequately when they are all running. I STILL haven't foudn anything to replace it with for a reasonable amount of money. Nothing in the Sun price range can handle that I/O volume. The Sun 3/160 can't even handle ONE streamer tape adequately in my opinion and the 3/260 is only a little better. (Maybe if they bother to supply a real VME board instead of the joke multibus boards with adaptor that they are trying to pass off as VME boards). Disk I/O is not great either. Also, because of the limited number of contexts the sun can keep, the Vax will often win if there are many processes active. Sun (and most others) have been concentrating on raw CPU speed and ignoring total system throughput. This is tolerable if you are buliding single user workstations, but unacceptable if you are looking at multiple users. -le.t I
roger@telesoft.UUCP (Roger Arnold @prodigal) (09/03/87)
> Many of the software people are among those clamoring for simplicity of > hardware design, mostly because the hardware designers have such a history > of getting things wrong when they try to be clever. Well, that's not entirely fair. "Clever" hardware designs have generally worked out fine, for the particular language/environment that the designers were thinking about when they did the designs. And if the designers up front about what they're doing, specialized designs can be very successful. The problem comes when they try to get clever in systems intended to be general.
glg@sfsup.UUCP (G.Gleason) (09/03/87)
In article <1221@pdn.UUCP> alan@pdn.UUCP (0000-Alan Lovejoy) writes: >There is a fixed cost associated with executing an instruction that has >nothing to do with how 'simple' or 'complex' it is (the number of bits >needed to encode the instruction IS important, however). This argues >that instructions should perform as much work as possible. >Instructions that perform a lot of work may do more work than was >needed, wasting machine resources. This argues that instructions should >do as little work as possible. In considering why RISC is such a big win, the most important thing is not so much that complex instructions do more than they have to, but that implementing them takes more chip area, and therefore slows down ALL of the instructions. What makes the RISC processors so fast is that all this extra chip area is devoted to pipelining, caches, etc. Since it turns out that the complex instructions always make up a small percentage of the executed instructions, and so no matter how much faster they are, they don't gain much. Incidentally, instruction size may be important, but not all that important. Clearly all the instructions do come in over the bus, and therefore bus bandwidth can be a limiting factor, but it is not nearly as important with an internal instruction cache. One RISC architecture I have worked with has a cache that holds decoded instructions, which if you think about it functions a lot like a micro-code store for any routine that fits in the cache. Who needs complex instructions or a micro-store when you have in effect an automatic micro-store. What the RISC approach represents, is really looking at what costs what, and putting complexity into the hardware only when this buys you something significant, not just because it seems like a neat idea. Gerry Gleason
eugene@pioneer.UUCP (09/03/87)
Mike (I'll be mellow when I'm dead) Meyer writes: >It hasn't been that long since, if you really wanted to run Unix, you >either had a 780 (no 750 back then) or a PDP-11, I was thinking about posting this from a PDP-11/70 we have ;-). [I started on a 45, sigh!]. >Since most sites worrying about mini/supermini-sized Unix boxes will >have someone around who has a feel for what a 780 is/does, they make a >good benchmark standard. > > Marketteer (sic): "This machine is 1e23 11/780 mips." > Eugene: "What's an 11/780." ;-) > Marketteer: "Dunno. We've always used them to measure machines, though." No, "Gold plating please. [National Bureau of Standards]." If you want some fun, when a Mousekteer (sic) [not a wizard] quotes a Whetstone or a Dhrystone, or whatever, ask them if they know what it is or can cite the original reference. 9 out of 10 can't answer. Have fun. From the Rock of Ages Home for Retired Hackers: --eugene miya NASA Ames Research Center eugene@ames-aurora.ARPA "You trust the `reply' command with all those different mailers out there?" "Send mail, avoid follow-ups. If enough, I'll summarize." {hplabs,hao,ihnp4,decwrl,allegra,tektronix,menlo70}!ames!aurora!eugene
jmoore@stan.UUCP (Jim Moore) (09/03/87)
In article <13439@amdahl.amdahl.com>, mat@amdahl.amdahl.com (Mike Taylor) writes: > In article <4949@jade.BERKELEY.EDU>, mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) writes: > > Of course, as someone who deals with large timeshareing Unix boxes, > > I'll be happy to tell you why a Sun 3/xx at 2 or 3 11/780 mips won't > > replace a real 780..... > > > I think that would be an interesting discussion. I, for one, would be > interested in your views. Perhaps you might kick things off.... > > > -- > Mike Taylor ...!{ihnp4,hplabs,amd,sun}!amdahl!mat I have never seen any indication that SUN ever represented a Sun/3 as a 780 replacement or a timesharing machine at all. The only reason that I can think of that would prohibit this use would be the 8 context direct mapped MMU. The VMEbus can hold its own with a Massbus or Unibus. The 3/260 can hold enough memory and has a hefty CPU compared to a 780. Is the MMU a serious bottle to timesharing? I think a discussion about the Sun/4 would be more appropriate as SUN does seem to be pushing this machine as a server including timesharing capabilities. Jim Moore SAE, Longmont Colorado
crowl@cs.rochester.edu (Lawrence Crowl) (09/04/87)
In article <1297@geac.UUCP> john@geac.UUCP (John Henshaw) writes: >..., software is more "malleable" than hardware and therefore in many ways, >far easier to work with than hardware. This of course means that it provides >plenty of opportunity to make mistakes, but I believe that the cost of >repairing those software mistakes is *usually* lower than that of hardware. Yes. A thousand chip board is far less mallable than a thousand line program. However, most systems tend to have hardware on the order of a thousand chips and software on the order of a million lines of code. A thousand chip board is probably easier to get right (by whatever measure) than a million line program. However, field upgrades are much cheaper for software than hardware. -- Lawrence Crowl 716-275-8479 University of Rochester crowl@cs.rochester.arpa Computer Science Department ...!{allegra,decvax,seismo}!rochester!crowl Rochester, New York, 14627
eugene@pioneer.arpa (Eugene Miya N.) (09/04/87)
I really have to get back to work, but Lawrence Crowl writes: >In article <1297@geac.UUCP> john@geac.UUCP (John Henshaw) writes: >>..., software is more "malleable" than hardware and therefore in many ways, >>far easier to work with than hardware. >> . . . but I believe that the cost of >>repairing those software mistakes is *usually* lower than that of hardware. > >Yes. A thousand chip board is far less mallable than a thousand line program. This is sort of like those sci-fi movies with insects slowly taking over the world. If hardware is so `hard,' how come there are all these COBOL and FORTRAN (and LISP, and soon Pascal and C) dusty decks, I mean, programs lying around? ;-) No, I think they should switch names. The advantage of the physical is that they are improved thru advances in the technology. I wonder about the same for virtual-ware. Belady (then with IBM) did a study about the point of diminishing returns on bugs. Consider that the program that does my pay check is lots older than the machine it probably runs on. Sounds like a B-52. Seems a lot "harder" to me. Think about it. The Program that would not die! (Sci-fi movie ;-) From the Rock of Ages Home for Retired Hackers: --eugene miya NASA Ames Research Center eugene@ames-aurora.ARPA "You trust the `reply' command with all those different mailers out there?" "Send mail, avoid follow-ups. If enough, I'll summarize." {hplabs,hao,ihnp4,decwrl,allegra,tektronix,menlo70}!ames!aurora!eugene
pf@diab.UUCP (Per Fogelstrom) (09/05/87)
In article <8542@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> 2. One other point that is interesting (my oppinion) is how >> much easier it has become for people to access computers. >> Compare "The Dark Ages" where computer installations was >> so called "Closed Shops" whith the PC world today... > >Actually, this is not "easier access" but "easy access at a lower price". >The micro people have rediscovered what some of us had with minicomputers >15 years ago, and some of the mainframe people had still earlier. Walking >up to the computer, sitting down, and starting work has always been possible, >if your employer was willing to pay enough. >-- May i make myself a litle bit more clear ?? 1. Software of today is much more "user friendly" and aimed for people with very litle experience from computers. Compare what we had for the PDP8 and NOVA computers for example. My mother who knows nothing about computers can handle a PC. But i wouldn't dare to think of what should happen if i let her lose on a PDP8. :-) 2. My first computer, the IBM1401 is not what i would have liked to have in my garage. Even then.... And was that one easy to use. A pc is something i can have on my desk. 3. I can, today get a computer with my own funds. Need more arguments....?
mjl@tropix.UUCP (Mike Lutz) (09/05/87)
In article <495@telesoft.UUCP> roger@telesoft.UUCP (Roger Arnold @prodigal) writes: >> Many of the software people are among those clamoring for simplicity of >> hardware design, mostly because the hardware designers have such a history >> of getting things wrong when they try to be clever. > >Well, that's not entirely fair. "Clever" hardware designs have >generally worked out fine, for the particular language/environment >that the designers were thinking about when they did the designs. In the first paragraph, I think clever is being used in the sense of "cute", or "tricky", and I entirely agree that such cleverness is at the heart of most CISC problems. In the second paragraph, clever is used in the sense of "ingenious", "skillful", or "resourceful". This second sense, which borders on "elegant", can be applied equally well to special purpose hardware and to RISC designs. Mike Lutz
ram%shukra@Sun.COM (Renu Raman, Sun Microsystems) (09/05/87)
In article <2670@ames.arpa>, eugene@pioneer.arpa (Eugene Miya N.) writes: > I really have to get back to work, but Lawrence Crowl writes: > >In article <1297@geac.UUCP> john@geac.UUCP (John Henshaw) writes: > >>..., software is more "malleable" than hardware and therefore in many ways, > >>far easier to work with than hardware. > >> . . . but I believe that the cost of > >>repairing those software mistakes is *usually* lower than that of hardware. > > > >Yes. A thousand chip board is far less mallable than a thousand line program. > > [....] > the world. If hardware is so `hard,' how come there are all these COBOL > and FORTRAN (and LISP, and soon Pascal and C) dusty decks, I mean, programs > lying around? ;-) No, I think they should switch names. The advantage of > [....] > > --eugene miya Lets not get confused between hard(ness/ware), soft(ness/ware) and malleable. I am reminded of grand old uncle Edsgar Djisktra quote (I think during his Turing award lecture) "Fortran's tragic fate has been its wide acceptance, mentally chaining thousands and thousands of programmers to our past mistakes. I pray daily that more of my fellow-programmers may find the means of freeing themselves from the curse of compatibility". --------------------- Renu Raman ARPA:ram@sun.com Sun Microsystems UUCP:{ucbvax,seismo,hplabs}!sun!ram M/S 5-40, 2500 Garcia Avenue, Mt. View, CA 94043
rpw3@amdcad.AMD.COM (Rob Warnock) (09/09/87)
(*Sigh*) I can't let this one go by... In article <301@ma.diab.UUCP> pf@ma.UUCP (Per Fogelstrom) writes: +--------------- | In article <8542@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: | >Actually, this is not "easier access" but "easy access at a lower price". | >The micro people have rediscovered what some of us had with minicomputers | >15 years ago... | May i make myself a litle bit more clear ?? | 1. Software of today is much more "user friendly" and aimed for people | with very litle experience from computers. Compare what we had for | the PDP8 and NOVA computers for example. My mother who knows nothing | about computers can handle a PC. But i wouldn't dare to think of | what should happen if i let her lose on a PDP8. :-) +--------------- Hurumph! OS-8 doesn't compare so badly against MS/DOS, thank you! Virtually identical user interface to a (subset of a) PDP-10 running TOPS-10. In the late 1970's at Dig. Comm. Assoc. we had secretaries who switched back and forth from PDP-8/OS-8 systems to PDP-11/RT-11 to PDP-10/TOPS-10 and never got lost. (They used TECO to edit and RUNOFF to do text processing on all three machines.) Remember that TOPS-10/RT-11/OS-8 were the indirect intellectual parents of CP/M and MS/DOS. On a PDP-8 (8k words) you could compile/link/execute FORTRAN and DIBOL (ugh!) and assembler, run (interpretively) BASIC & FOCAL, and on a 12k machine you could get batch processing, and on a 16k machine do it all while you were doing real-time data collection! (A "k" of PDP-8 words ~= 1.5kbytes.) Hey, and let's not forget user-written loadable device drivers (*ALL* device drivers except the root disk were "loadable" ;-} ). It wasn't all that great by Unix standards, primarily due to no "fork()" in the O/S, but it was not all that much worse than the so-called "user friendly" PC. Yes, there was no "Lotus 1-2-3", but I'm not sure how "friendly" that is anyway, once you get past the playing-around stage. A bare PDP-8/a with 16k (of non-DEC RAM) cost around $2000 in quantity circa 1978. You could put together an "o.k." WP system for about $4K, or buy DEC's "WPS-8" for $5K or so. Not too bad... <<end nostalgia mode>> Rob Warnock Systems Architecture Consultant UUCP: {amdcad,fortune,sun,attmail}!redwood!rpw3 ATTmail: !rpw3 DDD: (415)572-2607 USPS: 627 26th Ave, San Mateo, CA 94403
del@homxc.UUCP (D.LEASURE) (09/10/87)
software is hard hardware is soft Has anyone else noticed? -- David E. Leasure HR 59253 2F-239 x5307 homxc!del
ram%shukra@Sun.COM (Renu Raman, Sun Microsystems) (09/11/87)
.... and Firmware is brittle
---------------------
Renu Raman ARPA:ram@sun.com
Sun Microsystems UUCP:{ucbvax,seismo,hplabs}!sun!ram
M/S 5-40, 2500 Garcia Avenue,
Mt. View, CA 94043ebg@clsib21.UUCP (Ed Gordon) (09/11/87)
And then, according to Scandanavian Design's billing department, there is" "edware"
ram%shukra@Sun.COM (Renu Raman, Sun Microsystems) (09/11/87)
..... And beWARE of elastic Stoneware
Dhry---\
Whet-----Stone(ware).
Rolling/
---------------------
Renu Raman ARPA:ram@sun.com
Sun Microsystems UUCP:{ucbvax,seismo,hplabs}!sun!ram
M/S 5-40, 2500 Garcia Avenue,
Mt. View, CA 94043nather@ut-sally.UUCP (09/12/87)
Orson Scott Card coined the term "wetware" ... meaning bio-organisms, who,
when struck too hard, splash ... e.g., us.
--
Ed Nather
Astronomy Dept, U of Texas @ Austin
{allegra,ihnp4}!{noao,ut-sally}!utastro!nather
nather@astro.AS.UTEXAS.EDUcik@l.cc.purdue.edu (Herman Rubin) (09/13/87)
In article <8992@ut-sally.UUCP>, nather@ut-sally.UUCP (Ed Nather) writes: > Orson Scott Card coined the term "wetware" ... meaning bio-organisms, who, > when struck too hard, splash ... e.g., us. The term wetware is very old. In 1965, I was told this term (in distinction to hardware and software) by someone at IBM in San Jose. He said where he got it, but I do not remember. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (ARPA or UUCP) or hrubin@purccvm.bitnet
doug@edge.UUCP (Doug Pardee) (09/15/87)
[Note: my employer *definitely* has a vested interest in this, but I don't speak for them.] > In considering why RISC is such a big win, the most important thing is > not so much that complex instructions do more than they have to, but > that implementing them takes more chip area, and therefore slows down > ALL of the instructions. What makes the RISC processors so fast is that > all this extra chip area is devoted to pipelining, caches, etc. Er, all of this presumes that you're hell-bent on making a single-chip CPU. We here at Edge make a nice little machine which has a fully 68010 compatible instruction set, and which executes most instructions in one clock cycle (just like them there RISC machines). No, it doesn't fit on one chip. More like a dozen. But then, our memory boards have more than one chip on 'em too :-) -- Doug Pardee, Edge Computer; ihnp4!oliveb!edge!doug, seismo!ism780c!edge!doug
david@sun.uucp (David DiGiacomo) (09/16/87)
In article <945@edge.UUCP> doug@edge.UUCP (Doug Pardee) writes: >> In considering why RISC is such a big win, the most important thing is >> not so much that complex instructions do more than they have to, but >> that implementing them takes more chip area, and therefore slows down >> ALL of the instructions. What makes the RISC processors so fast is that >> all this extra chip area is devoted to pipelining, caches, etc. > >Er, all of this presumes that you're hell-bent on making a single-chip CPU. > >We here at Edge make a nice little machine which has a fully 68010 >compatible instruction set, and which executes most instructions in >one clock cycle (just like them there RISC machines). I get the impression from recent magazine blurbs that the Edge boxes are about twice as expensive as RISC systems with similar performance. Perhaps this is due to the severe cost penalties of multi-{semi-}custom chip CPU implementation. Doug, can you provide any cost/performance information? -- David DiGiacomo, Sun Microsystems, Mt. View, CA sun!david david@sun.com
mash@mips.UUCP (John Mashey) (09/16/87)
In article <945@edge.UUCP> doug@edge.UUCP (Doug Pardee) writes: >We here at Edge make a nice little machine which has a fully 68010 >compatible instruction set, and which executes most instructions in >one clock cycle (just like them there RISC machines). 68010 compatible? (was this a typo?) Note: as has been noted earlier in this sequence, you can make most architectures go fast if you throw lots of hardware at them to get more parallelism. VLSI RISC designs are trying to get the performance without burning lots of hardware and $$. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!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
bcase@apple.UUCP (Brian Case) (09/16/87)
In article <945@edge.UUCP> doug@edge.UUCP (Doug Pardee) writes: >Er, all of this presumes that you're hell-bent on making a single-chip CPU. > >We here at Edge make a nice little machine which has a fully 68010 >compatible instruction set, and which executes most instructions in >one clock cycle (just like them there RISC machines). > >No, it doesn't fit on one chip. More like a dozen. >But then, our memory boards have more than one chip on 'em too :-) Well, I must say that a few months of employment at a relatively high- volume manufacturer has done wonders to increase my awareness of cost sensitivity; that is, system cost is everything. (I was stunned to see how far, say, $50 can go when you really put your mind to it.) That is why it is so important to have as much on one chip as possible, and to have that chip mean something even without caches, etc. However, the Edge stuff is incredible when you think about the task at hand. I thought the latest incarnation fits in only 6 gate arrays (just the processor I mean), true?
glg@sfsup.UUCP (G.Gleason) (09/23/87)
In article <945@edge.UUCP> doug@edge.UUCP writes: >> In considering why RISC is such a big win, the most important thing is >> not so much that complex instructions do more than they have to, but >> that implementing them takes more chip area, and therefore slows down >> ALL of the instructions. What makes the RISC processors so fast is that >> all this extra chip area is devoted to pipelining, caches, etc. >Er, all of this presumes that you're hell-bent on making a single-chip CPU. >We here at Edge make a nice little machine which has a fully 68010 >compatible instruction set, and which executes most instructions in >one clock cycle (just like them there RISC machines). >No, it doesn't fit on one chip. More like a dozen. Don't forget that you get big performance benifits by keeping things on one chip, since it is expensive in both time and power to drive off chip loads. MIPS manages to bury almost all of the memory management overhead within the normal instruction cycle by putting a translation cache on the chip. Also, the next generation of single chip processors will be very difficult to beat, unless you go to exotic technologies (ie. expensive) Bus bandwidth is becoming a major bottleneck for most processors, and the only solution is to eliminate them from the artchitecture, or by shrinking the circuit so some busses are completely contained on a chip. Gerry Gleason
doug@edge.UUCP (Doug Pardee) (09/25/87)
In response to my comment that many of the "RISC wins" only exist if one is insistent upon putting the CPU into a single chip, Gerry Gleason says: >Don't forget that you get big performance benifits by keeping things on >one chip, since it is expensive in both time and power to drive off chip >loads... >Bus bandwidth is becoming a major bottleneck for most processors, and the >only solution is to eliminate them from the artchitecture, or by shrinking >the circuit so some busses are completely contained on a chip. I wonder if Seymour Cray knows that he's barking up the wrong tree by designing multiple-chip CPUs? Somebody ought to tell him :-) At this point I'm going to let the subject drop. There are already too many companies whose postings to comp.arch are nearly indistinguishable from marketing propaganda. Maybe we should form comp.arch.vested-interest? :-) [the usual disclaimer: If Edge wanted someone to speak for them, they sure wouldn't pick *me*!] -- Doug Pardee -- Edge Computer Corp., Scottsdale, AZ -- ihnp4!oliveb!edge!doug
bcase@apple.UUCP (Brian Case) (09/27/87)
In article <954@edge.UUCP> doug@edge.UUCP (Doug Pardee) writes: >In response to my comment that many of the "RISC wins" only exist if one >is insistent upon putting the CPU into a single chip, Gerry Gleason says: > >>Don't forget that you get big performance benifits by keeping things on >>one chip, since it is expensive in both time and power to drive off chip >>loads... >>Bus bandwidth is becoming a major bottleneck for most processors, and the >>only solution is to eliminate them from the artchitecture, or by shrinking >>the circuit so some busses are completely contained on a chip. > >I wonder if Seymour Cray knows that he's barking up the wrong tree by >designing multiple-chip CPUs? Somebody ought to tell him :-) Oops, a slightly different design center, I think. ECL (GaAs), terminated differential lines, etc. are a little beyond even what EDGE is probably willing to charge for. >At this point I'm going to let the subject drop. There are already too many >companies whose postings to comp.arch are nearly indistinguishable from >marketing propaganda. Maybe we should form comp.arch.vested-interest? :-) Hey, I like that idea. Unfortunately, it might deteriorate into comp.arch.flame, but maybe another forum (mail list)?
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (09/28/87)
In article <954@edge.UUCP> doug@edge.UUCP (Doug Pardee) writes: | ... |I wonder if Seymour Cray knows that he's barking up the wrong tree by |designing multiple-chip CPUs? Somebody ought to tell him :-) Actually I think someone did. I read that his chief designer for advanced products was "allowed to resign" when the single chip processor was advocated over the multichip GaS version. Said designer then left to form his own company. This is an old story... when a company gets "mature" and conservative people leave. Cray and Amdahl were other examples. If someone can find the name of the engineer and any more details please post. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me