mash@mips.COM (John Mashey) (11/18/89)
In article <3024@brazos.Rice.edu> preston@titan.rice.edu (Preston Briggs) writes: >In article <22303@gryphon.COM> scarter@gryphon.COM (Scott Carter) writes: > >>ISSUE one instruction per cycle. The 960 CA can issue three instructions per >>cycle to the chosen three of four execute units. I believe Intel has figures >>showing that on the average they could infact issue two instructions per clock >>_average_ [over what program set?], hence the 960CA can legitimately be called >>66 Native MIPS average with 99 Native MIPS peak. As hawkes said, MIPSco uses a rating system that tries to approximate performance versus a VAX-11/780 with good compilers on a mixture of large program that do include both integer and floating-point computations. Peak native instruction rates have NOTHING to do with such ratings, i.e., they tell you nothing about the speed of chips in systems running real programs. Only benchmarks of real programs on real machines do that... >I think that's too optimistic. >We've played some with an i860 on an evaluation board. >The supplied compilers didn't attempt to issue more than >1 instruction/cycle (out of a max of three). Note: I think this statement is offering data (thanx!) on a related issue, and did not confuse the two chips, but just to make sure, i860s and i960s are completely different chips. To answer the question that started this all, the R6000 and i960 are about as far apart in usage as one can imagine. The i960 is clearly targeted at embedded control, and the i960CA has neither FPU nor MMU (which is perfectly OK), hence it is unlikely that you'll see it running the SPEC benchmarks any time soon..... One of the topics of discussion at the Microprocessor Forum was that the benchmark confusion in the embedded side of the world is even worse than in the systems side... -- -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
preston@titan.rice.edu (Preston Briggs) (11/19/89)
In article <31659@winchester.mips.COM> mash@mips.COM (John Mashey) writes: >In article <3024@brazos.Rice.edu> preston@titan.rice.edu (Preston Briggs) writes: >>We've played some with an i860 on an evaluation board. >>The supplied compilers didn't attempt to issue more than >>1 instruction/cycle (out of a max of three). > >Note: I think this statement is offering data (thanx!) on a related issue, >and did not confuse the two chips, but just to make sure, >i860s and i960s are completely different chips. Right. I was just trying to cast aspersions on data that suggest we're going to see an average of 2 instructions/cycle sometime this decade (wow, big claim). It might be a couple of years. The problem is lack of compilers, not the chips. On the other hand, Multiflow has probably been doing it for years. Preston
mash@mips.COM (John Mashey) (11/19/89)
In article <3044@brazos.Rice.edu> preston@titan.rice.edu (Preston Briggs) writes: >Right. I was just trying to cast aspersions on data that suggest we're >going to see an average of 2 instructions/cycle sometime this decade >(wow, big claim). It might be a couple of years. >The problem is lack of compilers, not the chips. >On the other hand, Multiflow has probably been doing it for years. Actually, the Multiflow is a positive example of designing hardware and software together and making the tradeoffs in hardware according to what compilers might ACTUALLY do, not what hand-written code can do. One cannot just blame the compilers for not taking advantage of all of the features, especially if compiler writers were not heavily involved in the design. Some readers may recall the last session at the Hot Chips conference, in which some experienced compiler writers bemoaned the berserkery of some chip designs, and the general lag of compilers behind chip designs. I especially liked Steve Johnson's discussion of how compiler writers, even if asked about chip design (usually aren't) seldom have enough time to help it because they're frenziedly trying to catch up with the previous thing. He showed a nice hunk of pseudo-code: "CRISIS -- COMPILERS LAG HARDWARE repeat { Compiler writers work on last generation Chip dsigners design next generation THUS: next chips hard to compile for } until ( we wise up ) " Now of course, it may well be that in RESEARCH projects, one is exploring what can be done, and trying to understand the implications, and this may lead to designs that stretch compilers heavily [presumably done as part of same project :-)]. but it is amazing to see people doing this for things expected to be commercial, reprogrammable products.... Of course, everything said for compiler writers goes for operating systems folks as well, at least. -- -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
crisp@mips.COM (Richard Crisp) (11/19/89)
In the November 27th issue of Business Week is an article about the RISC chip revolution. The first page of the article has information whose source is given as IN-STAT Inc. They show a table listing the performance of several microprocessors including MIPS, 88K, SPARC, Clipper, 29K, '860 and two CISC machines, the 68030 and the '486. The Table is reproduced below: R3000 25MHZ 20MIPS 88K 25MHZ 17MIPS SPARC 33MHZ 16MIPS Clipper 60MHZ 16MIPS 88K 20MHZ 13MIPS 29K 12MHZ 12MIPS 486 25MHZ 15MIPS 860 33MHZ 15MIPS 68030 33MHZ 6MIPS Has anyone got any idea how IN-STAT arrives at their numbers? -- Just the facts Ma'am
mcg@mipon2.intel.com (Steven McGeady) (11/28/89)
In article <3044@brazos.Rice.edu>, preston@titan.rice.edu (Preston Briggs) writes: > >and did not confuse the two chips, but just to make sure, > >i860s and i960s are completely different chips. > > Right. I was just trying to cast aspersions on data that suggest we're > going to see an average of 2 instructions/cycle sometime this decade > (wow, big claim). It might be a couple of years. > The problem is lack of compilers, not the chips. Cast all the aspersions that you wish, but the 960CA can and does execute useful hand-written assembly-language code at a sustained rate of two instructions per clock. How useful is this to the average UNIX user? Not at all (at least right at the moment). The 960CA is an embedded controller. However, one can code a matrix multiply, bresenham, bezier, or other function to run at this sustained rate. In order to run on *all* code at a sustained rate of 2 instructions/clock, and normal (that is, non-VLIW) architecture would have to be capable of fetching and decoding far more than the 3 instructions per clock that the 960CA attempts. What is useful is that the 960CA can overlap the *dispatch* as well as the execution of the instruction stream, so that the sequence: addi g0,g1,g2 ldq (g0),g4 # load 4 words into g4..g7 addi g2,g3,g0 is executed in 2 clocks (though the load instruction will not return until some time later, depending on the latency of memory). The instruction stream will continue to be executed until g4,g5,g6, or g7 is used as a source operand in another instruction. With good scheduling technology, this will be several more instructions. So the 960CA introduces a new technique that dramatically increases the potential amount of parallelism available, without resorting to VLIW schemes that chew up memory space and bandwidth. This is what's new and important about the CA. Attached to the end of this article is a real program that runs at 66 native mips on the 960CA. > On the other hand, Multiflow has probably been doing it for years. Only if you assume a rich floating-point mix in their calculations. I doubt very much whether the kernel runs at 2 instructions/clock. That is our goal (albeit not yet realized). S. McGeady Intel Corp.