mostek@motcid.UUCP (Frank B. Mostek) (02/09/91)
There is an excellent article (An Elementary C Cost Model by Bentley, Kernighan, and Vanwyk) in the February issue (Vol.9 No. 2) of Unix Review that supposedly will enable the reader to run an experiment on his/her machine which would estimate the cost of a given operation to within 25 percent. Happy reading! -- ************************************************************ Frank Mostek uunet!motcid!amethyst!mostek Motorola Inc. (708)632-7191 ************************************************************
bill@hcx2.ssd.csd.harris.com (Bill Leonard) (02/13/91)
In article <5778@beryl12.UUCP>, mostek@motcid.UUCP (Frank B. Mostek) writes: > There is an excellent article ... that supposedly will enable the reader > to run an experiment on his/her machine which would estimate the cost of > a given operation to within 25 percent. I haven't read the article, but I wouldn't believe it if this is truly what it says. I know that, on our Motorola M88100-based machines, the cost of a floating-point divide (for instance) can vary a lot more than 25%. The M88100 can overlap operations so that the divide can appear to be almost entirely free, _if_ there is other work to do. Other operations can vary similarly. -- Bill Leonard Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.csd.harris.com
meissner@osf.org (Michael Meissner) (02/15/91)
In article <2340@travis.csd.harris.com> bill@hcx2.ssd.csd.harris.com (Bill Leonard) writes: | In article <5778@beryl12.UUCP>, mostek@motcid.UUCP (Frank B. Mostek) writes: | > There is an excellent article ... that supposedly will enable the reader | > to run an experiment on his/her machine which would estimate the cost of | > a given operation to within 25 percent. | | I haven't read the article, but I wouldn't believe it if this is truly what | it says. I know that, on our Motorola M88100-based machines, the cost of a | floating-point divide (for instance) can vary a lot more than 25%. The | M88100 can overlap operations so that the divide can appear to be almost | entirely free, _if_ there is other work to do. Other operations can vary | similarly. While the general point applies, I think you choose a bad example. On the 88k, single precision divides are 30 clocks and double precision divides are 60 clocks. It's hard to keep the machine busy for that many clocks before needing the divide results. In signed integer divides it is worse in that the compiler generally has to account for the signedness of the operands with branches and such, which means if either operand is negative you typically must do a negate directly after the divide, stalling the pipeline. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?
snoopy@sopwith (Snoopy) (02/15/91)
In article <5778@beryl12.UUCP> mostek@motcid.UUCP (Frank B. Mostek) writes: | There is an excellent article (An Elementary C Cost Model by Bentley, | Kernighan, and Vanwyk) in the February issue (Vol.9 No. 2) of Unix | Review that supposedly will enable the reader to run an experiment on | his/her machine which would estimate the cost of a given operation to | within 25 percent. Is the code available without having to type it in from the magazine article? _____ /_____\ Snoopy /_______\ cse.ogi.edu!sopwith!snoopy |___| sun!nosun!qiclab!sopwith!snoopy |___| uunet!tektronix!nosun!qiclab!sopwith!snoopy
bill@hcx2.ssd.csd.harris.com (Bill Leonard) (02/19/91)
In article <MEISSNER.91Feb14112644@curley.osf.org>, meissner@osf.org (Michael Meissner) writes: > While the general point applies, I think you choose a bad example. On > the 88k, single precision divides are 30 clocks and double precision > divides are 60 clocks. It's hard to keep the machine busy for that > many clocks before needing the divide results. I'd agree it's hard to keep the machine busy for the entire 30-60 clocks, but it's usually not hard to do quite a bit of useful work in there. So there are two points: 1) the cost of the divide may be significantly less than 30 or 60 clocks; 2) the cost of those operations that were done while the divide was executing _appears_ to be zero in this case, whereas they would be non-zero if done in isolation. Nevertheless, I recently examined the code for a FORTRAN program that contained quite a few floating-point operations (including divides) in a monstrously long section of straight-line code. Several of the divisions were completely overlapped with other operations. Difficult, yes, impossible, no. > In signed integer divides it is worse in that the compiler generally has > to account for the signedness of the operands with branches and such, > which means if either operand is negative you typically must do a negate > directly after the divide, stalling the pipeline. A reasonably good instruction scheduler should be able to insert other instructions between the divide and the negate, if there's anything useful to do. -- Bill Leonard Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.csd.harris.com