Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!mtune!codas!usfvax2!pdn!alan From: alan@pdn.UUCP Newsgroups: comp.arch Subject: Re: brash micros versus the Big Iron: not yet Message-ID: <1221@pdn.UUCP> Date: Tue, 1-Sep-87 11:36:11 EDT Article-I.D.: pdn.1221 Posted: Tue Sep 1 11:36:11 1987 Date-Received: Wed, 2-Sep-87 07:17:05 EDT References: <622@winchester.UUCP> <12953@amdahl.amdahl.com> <630@winchester.UUCP> <1202@pdn.UUCP> <640@winchester.UUCP> Reply-To: alan@pdn.UUCP (0000-Alan Lovejoy) Organization: Paradyne Corporation, Largo, Florida Lines: 77 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: 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