Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!rice!titan!preston From: preston@titan.rice.edu (Preston Briggs) Newsgroups: comp.lang.misc Subject: Re: function calls Message-ID: <6170@brazos.Rice.edu> Date: 30 Mar 90 00:28:36 GMT References: <29551@amdcad.AMD.COM> <6076@brazos.Rice.edu> Sender: root@rice.edu Organization: Rice University, Houston Lines: 70 In pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) writes many things. Among them, he responds to my comment that > CPU's outrun memory. They have been for years, and memory > isn't catching up. Hence the development of caches, multi-level caches, > wide data busses, and large register sets. > >Von Neumann's bottleneck? Who said bottleneck? The guy from Thinking >Technologies down the hall? :-> Nobody I know knows about Thinking Technologies. Who are they? My initial guess was that you meant Danny Hillis at Thinking Machines. A smart man, but his machines are a little out my league. Further, naming the problem doesn't make it go away. It reality that memory costs money and that fast memory costs more money. Using multiple-levels in your hierarchy is an engineering tradeoff that works. >On general purpose architectures and codes, of >course. If you can otherwise predict access patterns, "registers" win >(can I say "vector codes"?). Sure. But the predictability and reuses arises due to loops and arrays, things that appear in many time-consuming chunks of code. Not every program fits, but many do, including programs written in Fortran, C, Pascal, Ada, ... >There is an uncertain tradeoff between generality and reliability and >complexity of hardware vs. software here. A particularly difficult >issue. My own rule is that complexity that is not supported by very big >sure advantages is to be regarded with the utmost suspicion, whether it >manifests itself as number of intructions, address modes, registers, >optimizers, and so on... I have sympathy with this position. I think most people outside the government do. However, I also recognize that some of these complexities, mastered, achieve performance. In particular, I think optimization is a Good Thing. It allows me to specify my programs in less time and with less complexity. It allows me to offload tedious, error-prone tasks onto the computer. To make an optimizer effective though, we need a large supply of registers. Without an adequate register set, our simplifying seperation of concerns (front end vs. optimization vs. instruction selection vs. register allocation) breaks down. Perhaps this doesn't appear simple! It isn't entirely, and hasn't always been recognized or possible. I think it's one of the under-emphasized results of the whole 801/PL.8 project. Hoare, in "Hints on Programming Language Design", wanted a language in which a simple straightforward "non-pessimising" compiler will produce straightforward object programs of acceptable compactness and efficiency... I think this is a tremendous suggestion. Further, I believe it's what Grandi has been pressing for. However, leaving out the optimization doesn't achieve these desired result. My optimizer (not the world's best or worst) produces remarkably straighforward code. I think it's what most people would want to see out of their compiler. (I'm not including the agressive source-to-source transformations I've talked about before.) I think it's just more difficult to produce "straightforward object programs of acceptable compactness and efficiency" than most people recognize. I believe it requires a fair amount of analysis and transformation (that is, optimization and register allocation). -- Preston Briggs looking for the great leap forward preston@titan.rice.edu