Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!world!iecc!compilers-sender From: hoelzle@neon.Stanford.EDU (Urs Hoelzle) Newsgroups: comp.compilers Subject: Re: Is inlining evil? Keywords: optimize, design Message-ID: <1991May4.005612.7207@neon.Stanford.EDU> Date: 4 May 91 00:56:12 GMT References: <7524@ecs.soton.ac.uk> <1991May1.035622.25021@daffy.cs.wisc.edu> <19 <9105031304.AA00625@slave.vlsivie.tuwien.ac.at> Sender: compilers-sender@iecc.cambridge.ma.us Reply-To: hoelzle@neon.Stanford.EDU (Urs Hoelzle) Organization: Computer Science Department, Stanford University, Ca , USA Lines: 30 Approved: compilers@iecc.cambridge.ma.us 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.