mike@vlsivie.tuwien.ac.at (Michael K. Gschwind) (05/04/91)
Preston Briggs writes: >Obviously, inlining is not completely Evil. >However, I think it has been over-sold and over-used. >This is a little attempt to even the balance. Yes, inlining can result in performance degradation, esp. cache effects can be awful, but judicious use of inlining is a Good Thing. If you inline (modestly) huge functions (< 10-20 % of I - cache size (?)), this will destroy any hint of locality. Take this example of C code: { ... huge_function(1); huge_function(2); huge_function(3); huge_function(4); ... } If you expand huge_function() four times in the object code, you'll probably get lots of cache misses, whereas if you actually call a function, you will huge_function will probably still reside in the cachw. (on the other hand, if you have many ridiculously short functions (such as simple C++ members), it increases locality.) Inline functions are far superior to macros (C hackers, please don't flood my mailbox ;-) in avoiding unwanted side effects, because they are supposed to have identical semantics when compared to `normal' functions. bye, mike Michael K. Gschwind, Dept. of VLSI-Design, Vienna University of Technology mike@vlsivie.tuwien.ac.at || mike@vlsivie.uucp Voice: (++43).1.58801 8144 || Fax: (++43).1.569697 -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.
hoelzle@neon.Stanford.EDU (Urs Hoelzle) (05/04/91)
mike@vlsivie.tuwien.ac.at (Michael K. Gschwind) writes: >Yes, inlining can result in performance degradation, esp. cache effects >can be awful, but judicious use of inlining is a Good Thing. If you >inline (modestly) huge functions (< 10-20 % of I - cache size (?)), this >will destroy any hint of locality. Take this example of C code: I keep seeing these ominous warnings about the Bad Things that happen when code size increases. Does anybody actually have data on this? I seem to remember one study where doubling the code size didn't change the code cache miss ratio very much. I suspect that with reasonably large I caches (say > 32K) code cache misses are not an issue when deciding wether to use inlining or not. Remember that doubling the I cache size doesn't buy you very much above a certain (read: reasonable) cache size. -Urs Disclaimer: sure, there will always be some cases where code size / I cache behavior *is* important - but I think they are the exception rather than the rule. -- ------------------------------------------------------------------------------ Urs Hoelzle hoelzle@cs.stanford.EDU Center for Integrated Systems, CIS 42, Stanford University, Stanford, CA 94305 -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.
quale@cs.wisc.edu (Douglas E. Quale) (05/05/91)
In article <9105031304.AA00625@slave.vlsivie.tuwien.ac.at> Michael K. Gschwind<mike@vlsivie.tuwien.ac.at> writes: >Inline functions are far superior to macros (C hackers, please don't flood >my mailbox ;-) in avoiding unwanted side effects, because they are >supposed to have identical semantics when compared to `normal' functions. This is certainly true, but it is largely due to the impotence of the C preprocessor. Languages such as Lisp that have more powerful macroprocessors do not have the multiple evaluation of parameters problem so common in C macros. Unfortunately Lisp macros have their problems too, but at least you can do something useful with them.... -- Doug Quale quale@saavik.cs.wisc.edu -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.
clark@ingr.com (Clark Williams) (05/06/91)
hoelzle@neon.Stanford.EDU (Urs Hoelzle) writes: > > I keep seeing these ominous warnings about the Bad Things that happen > when code size increases. Does anybody actually have data on this? I > seem to remember one study where doubling the code size didn't change > the code cache miss ratio very much. > Also, what about the case of expanding code size to take advantage of a deep pipeline? Isn't this working at cross purposes with attempting to maintain locality of reference? If you insert instructions into the instruction stream to keep the pipe full, are you shooting yourself in the foot as far as the cache hit rate is concerned? Has anyone run into this issue before? Clark Williams Intergraph Corp. ...uunet!ingr!clark (UUCP) clark@ingr.com (Internet) -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.
mjs@hpfcso.fc.hp.com (Marc Sabatella) (05/09/91)
Preston makes some good points about "naive inlining". But there is no
particular reason inlining need be so naive. The HP-UX C and Fortran
compilers for 680x0 do inlining under +O3, and the programmer is offered
considerable control over the inlining process via command line options
and compiler directives. The default for +O3 is to inline any function
that is under a certain size, but that measurement is made before any of
its own calls are inlined, so you can easily end up with a sort of
combinatorial explosion. However, you can set the size limit, also you
can (via directive) turn on or off inlining for a particular function, and
you can even turn off the inlining at the point of call, so that some
calls to a given function are inlined and others aren't. You can also
control whether standalone code for the function should also be emitted
(to allow external calls).
My own experience on a small but very "real" program is that after spending
a day or two experimenting, figuring out which calls to inline and which not
to, I ended up with a program that was 10% larger and 10% faster, and I
considered the whole deal to be a fair tradeoff of my time, run time, and
space.
--------------
Marc Sabatella (marc@hpmonk.fc.hp.com)
--
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.