Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cs.utexas.edu!bcm!dimacs.rutgers.edu!rutgers!rochester!pt.cs.cmu.edu!gandalf.cs.cmu.edu!lindsay From: lindsay@gandalf.cs.cmu.edu (Donald Lindsay) Newsgroups: comp.arch Subject: Re: Register Count Message-ID: <11570@pt.cs.cmu.edu> Date: 14 Jan 91 16:45:25 GMT References: <11566@pt.cs.cmu.edu> Organization: Carnegie Mellon Robotics Institute Lines: 52 In article pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >pcg> It is an old controversy, but let me repeat here: 90% of what >pcg> passes for "optimizing" compilers are compilers that optimize for >pcg> *space*, not time, ... >lindsay> The optimizing compilers that I worked on, were trying for >lindsay> speed. We tuned the things by endlessly recompiling and >lindsay> running our (ever-expanding) code-quality suite. We didn't >lindsay> bother to measure how small the generated code was: we just >lindsay> timed it. > >This seems (to me at least) a funny way of proceeding, and deomstrates a >trial-and-error mentality that may be there because of lack of insight. >It is sad that people like you spend lots of time in trial-and-error >attempts to get an "optimizer" going using possibly irrelevant >technology, instead of investigating important issues ... >Reread David Wall and company a million times... Or maybe the >David Wall in my world is a pop singer in yours :-). Hmmm. Some of my coworkers from that effort, have since been coworkers of David Wall. The idea that we lacked insight is amusing. The insight which you have missed, is that advanced optimization is heavily influenced by the statistical properties of the test suite. It is entirely possible to persuade one's colleagues to make some improvement, promising them wonders: and then discover that the code quality suite now runs slightly SLOWER. (Or - more usual and more agonizing - some programs are faster, but others are slower.) If you do not understand why this should be, then you have a non- quantitative understanding of the subject area. However, that was not the point that I was trying to make. I was pointing out, unambiguously, that our compilers were _clearly_ aiming for speed, not space. >lindsay> But, on the whole, stack architectures are dead, >Just as quantitative computer architecture is, if serious people can >delude themselves ... >I introduced the idea of multiple stacks ... >Maybe I should repeat the argument more clearly (hopefully). Clarity is not the issue: I am simply unconvinced that your proposal would be competitive if built. I encourage you to obtain quantitative supporting data. -- Don D.C.Lindsay .. temporarily at Carnegie Mellon Robotics