Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Uncle Steve Newsgroups: comp.lang.c Subject: Re: Malloc Query Date: Tue, 24 May 2011 11:32:46 -0400 Organization: Friends of the Galactic Collective Lines: 117 Message-ID: <7bfe0ef149bdbdd-a0468@gmail.com> References: <2b5874771e1859c-5f9fd@gmail.com> <22a91a32-b2c6-4ce1-bb2b-23c2455bc195@z13g2000yqg.googlegroups.com> <708913a057f3f9c-34aa7@gmail.com> <0.47b2d301a43a01009630.20110522231836BST.87fwo6nzur.fsf@bsb.me.uk> <21ceccb2e03a4dc-edfd3@gmail.com> <93tk6hFt2pU3@mid.individual.net> <93ugcsFt2pU6@mid.individual.net> <2cc0f0e084f264b-656fa@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Injection-Info: mx04.eternal-september.org; posting-host="HoLaDevQz+VWJX9t0+Um9g"; logging-data="28359"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19H9L/M+6akXuPoeRgbO1ZZ" User-Agent: nn 6.7.3 Content-Length: 5499 Cancel-Lock: sha1:M0k8iqSXZemcLwNk6/bQYVB1c4w= Xref: x330-a1.tempe.blueboxinc.net comp.lang.c:4699 On Tue, May 24, 2011 at 07:19:28AM -0400, James Kuyper wrote: > On 05/23/2011 02:20 PM, Uncle Steve wrote: > > On Mon, May 23, 2011 at 07:24:11PM +1200, Ian Collins wrote: > >> On 05/23/11 05:57 PM, Uncle Steve wrote: > ... > >>> For my purposes, it is > >>> sometimes nice to write a macro which uses conditionals to select a > >>> particular code path through the macro. If the conditional can be > >>> resolved at compile-time, the dead code branches in the macro are > >>> pruned, saving space. A similarly structured function call won't be > >>> optimized in this fashion unless (maybe) it is inlined. > >> > >> Why not? Whether the function is called or in line, the conditional > >> compiles are still there. > > > > A function is only inlined if it is defined in the same source file. > > Not quite - it only has to be in the same translation unit. A > translation unit consists of a given source file plus all of the other > files merged into it by #include statements. The use of the function > must also occur within the scope of the inline declaration, which > basically means that the declaration should occur prior to the use. > These requirements also apply to macros, though the scope rules are a > bit different for them. Sorry, I'm not up on the technical nomenclature pertinent to compilers. I *meant* to say 'translation unit', but all my brain had was 'source file'. > > If you define a function in an external source file, it cannot be > > inlined anywhere else unless the function is also defined in an > > included header file. Doesn't everyone know this? > > If you replace your function-like macro, wherever it is that you have it > defined, with an inline function definition in that same location, that > function will be usable pretty much wherever the the macro was usable. > It's probably feasible to come up with pathological contexts where a > simple in-place replacement won't work, but such contexts are not the norm. Agreed. > >> Inlining is a very simple optimisation. You also overlook the opposite > > > > No it isn't. > > Perhaps not, but it's one that most popular modern compilers do > routinely and very well; that's part of what makes them popular. Inline functions are easy to use, but who can measure the performance advantage of inlining versus the code size tradeoff? I have no idea how to accurately measure and quantify the real advantages, which may be different for every architecture and application. I suspect the trend of blindly setting CFLAGS=-O9, which is not all that uncommon in makefiles, masks a profound ignorance of what really goes on in a running program. I also suspect that the complex interaction of compile and run-time factors defies simplistic optimization heuristics. > >> optimisation - not inlining. There are situations where a smaller > >> executable performs better (or even fit the target device!). The > > > > In I wrote: > > > > Whether or not the code is inlined is going to depend more on > > whether you are interested in performance or code size. > > > > Fitting code in some machines' L1 cache is harder with a lot of > > gratuitous inlining, and you also pollute the l2 cache. Sometimes > > this matters, and sometimes not. All highly dependent on the > > specifics of the code and platform. > > Any decent compiler can be relied upon to take those issues into > consideration when deciding whether or not to inline a function. This is > something it can decide, independently of whether or not the function is > declared inline. As far as actual inlining is concerned, the 'inline' > keyword is only a hint, which a compiler is free to ignore; and it's > perfectly legal for a compiler to decide to inline a function that is > not declared 'inline', as long as doing so doesn't change the observable > behavior. In fact, that was one of the arguments given against the > introducing of the 'inline' keyword. Any static function written to meet > the same special requirements that currently apply to 'inline' functions > could already have been inlined, even if not so declared, so long as the > compiler thought that doing so would be a good idea. At least these compilers allow one to individually tune the optimization characteristic of the compilation process. If you don't want inlining, it's trivial to turn it off. > Unless you know a lot more about the target platform than your compiler > does, it's probably best to rely upon it to make inlining decisions. All things being equal, that is decent advice. > Defining a function (whether or not you use 'inline') gives it that > option. Defining it as a function-like macro does not - it only allows > inlining. Well, technically, I suppose a sufficiently sophisticated > compiler could perform anti-inlining: recognizing a common code pattern, > and replacing it wherever used with a call to a compiler-generated > function definition. The fact that the common code was the result of a > macro expansion would make it easier to recognize the feasibility of > such an optimization. However, and it seems to me to be a harder > optimization to perform than inlining, and I doubt that it is a common > feature even of the most sophisticated compilers. That kind of optimization would be the comp-sci equivalent of gilding the lily. Regards, Uncle Steve -- Should a professional politician be charged with molestation if he kisses babies while attending political rallies?