Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!think.com!mintaka!spdcc!iecc!compilers-sender From: boehm@parc.xerox.com (Hans Boehm) Newsgroups: comp.compilers Subject: Re: the Evil Effects of Inlining Keywords: optimize, architecture, Russell Message-ID: Date: 3 May 91 17:14:49 GMT References: <9104262025.AA21840@enuxva.eas.asu.edu> <7524@ecs.soton.ac.uk> <1991May1.035622.25021@daffy.cs.wisc.edu> <1991May2.180508.17100@rice.edu> Sender: compilers-sender@iecc.cambridge.ma.us Reply-To: boehm@parc.xerox.com (Hans Boehm) Organization: Xerox PARC Lines: 43 Approved: compilers@iecc.cambridge.ma.us It seems to me that all such evaluations are incredibly dependent on the source language and on the programming style. I would expect to see no improvement for Fortran code that was written by people who believed that procedure calls are very expensive and should be avoided like the plague. They presumably already did the profitable inlining themselves (and perhaps a little more). I wouldn't expect a lot of improvement in an average Pascal program either. In my experience, the place where inlining pays off a lot is for languages and coding styles that encourage operations on abstract data types to be expressed as separate procedures. In a well-written Modula-3 or Oberon program, I would expect to see a reasonable number of procedures that can be inlined to 2 or 3 instructions, with perhaps no additional register usage. A similar effect also occurs in the presence of generic functions, though that requires more work. If I invoke qsort with integer comparison, I would expect to gain a fair amount by cloning qsort, and inlining the comparison (which may effectively have a zero instruction count, since I save the test on the function result). My experience with inlining in Russell is very different from Preston's experience. But then both of the above issues apply (though I don't create more than one clone of a procedure). Furthermore all of the "primitives" like integer addition are conceptually procedures (that may be passed as parameters or assigned or reused by user defined types). Russell programs compiled without inlining are intolerably slow. (I don't recall exact numbers. A factor of 3-5 slower is a guess.) This is largely due to what would be primitives in other languages. But since it's common to slightly modify an existing type like "Float" to derive new types, the notion of a "primitve" is unclear, and a more general mechanism is clearly needed. I also like the idea of supplying most language "primitives" in predefined modules, and then letting inlining remove the performance distinction. None of this is astonishing or inconsistent with what Preston said. But it's important to only apply these results to their proper context. Hans (boehm@xerox.com) -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.