gl8f@astsun7.astro.Virginia.EDU (Greg Lindahl) (02/09/91)
In article <27B19A39.321E@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >Machines have been designed for efficient execution in the most common >cases. If the most common cases are compiled C and Fortran programs, >optimizing the hardware for those cases is only natural. > >Remember, Herman, your instruction mix is radically atypical. Actually, C and Fortran programs show a wide variety of "common cases". Algorithms change, and so does the optimal hardware. Example: 2 years ago my "typical" hydrodynamics code almost never did a square root. Now it does quite a lot of them. Had you designed your instruction set back then, and your competition covered their asses by slowing themselves down a little bit to provide good performance in a wider variety of situations. The only thing that bothers me more than Herman repeating himself repeatedly are people who give the knee-jerk answer "we know what optimal is", without realizing that many applications are atypical, and that they change over time. Yes, numerical hydrodynamics isn't a big fraction of the total money spent on computers, but you can come up with other examples if you think a bit. If you try to sell your risc chip without integer multiply to a company that has 10 million lines of Fortran code all written using 2d fortran arrays with adjustable bounds, you could be in deep shit. Optimize the common case, but cover your ass. [ No, I have no idea if what Herman wants is a useful way to hedge your bets, but I'm tired of seeing it flamed about in such a content-less fashion. ]
pcg@cs.aber.ac.uk (Piercarlo Grandi) (02/11/91)
On 9 Feb 91 00:41:31 GMT, gl8f@astsun7.astro.Virginia.EDU (Greg Lindahl)
said:
gl8f> In article <27B19A39.321E@tct.uucp> chip@tct.uucp (Chip
gl8f> Salzenberg) writes:
chip> Machines have been designed for efficient execution in the most
chip> common cases. If the most common cases are compiled C and Fortran
chip> programs, optimizing the hardware for those cases is only natural.
chip> Remember, Herman, your instruction mix is radically atypical.
gl8f> Actually, C and Fortran programs show a wide variety of "common
gl8f> cases". Algorithms change, and so does the optimal hardware.
gl8f> Example: 2 years ago my "typical" hydrodynamics code almost never
gl8f> did a square root. Now it does quite a lot of them. Had you
gl8f> designed your instruction set back then, and your competition
gl8f> covered their asses by slowing themselves down a little bit to
gl8f> provide good performance in a wider variety of situations. [ ... ]
gl8f> Optimize the common case, but cover your ass.
An architect! Incredible! On these screens! From the USA (East Coast,
though :->), too! Somebody who actually realizes that things that change
with time and variability is the rule, not the exception! Somebody who
is willing to pay a small price on the 80% to get a large gain on the 20%!
I think that this posting sums up a lot of the discussions about
architecture we have been having here. Architecture, whether about
boundaries between hardware layers, or software ones, or the boundary
between the two, is about the sort of things described above. And taking
very well reasoned bets.
Well, I hope the Imperial MITI DRAM Service does not put you on their
hit list :-).
--
Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk