Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| 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 <stevet810@gmail.com> |
| 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> (permalink) |
| 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> <c5fb887a0c3800b-63061@gmail.com> <93ugcsFt2pU6@mid.individual.net> <2cc0f0e084f264b-656fa@gmail.com> <irg480$pfj$1@dont-email.me> |
| 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 |
Show key headers only | View raw
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 <a8a6d14a9ed9b70-0c8ce@gmail.com> 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?
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Malloc Query Pushpa <pushpa@nospam.invalid> - 2011-05-17 19:39 +0000
Re: Malloc Query blp@cs.stanford.edu (Ben Pfaff) - 2011-05-17 12:55 -0700
Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-18 12:05 +0100
Re: Malloc Query Pushpa <pushpa@nospam.invalid> - 2011-05-18 17:11 +0000
Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-18 22:42 +0100
Re: Malloc Query Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-18 21:10 -0400
Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-18 19:34 +0100
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-18 17:10 -0400
Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-19 00:26 +0100
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-18 21:25 -0400
Re: Malloc Query James Kuyper <jameskuyper@verizon.net> - 2011-05-18 21:38 -0400
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-19 14:11 -0400
Re: Malloc Query James Kuyper <jameskuyper@verizon.net> - 2011-05-19 22:55 -0400
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-20 12:14 -0400
Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-19 03:22 +0100
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-19 14:20 -0400
Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-19 23:51 +0100
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-19 20:01 -0400
Re: Malloc Query luser- -droog <mijoryx@yahoo.com> - 2011-05-22 02:49 -0700
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-22 10:46 -0400
Re: Malloc Query Shao Miller <sha0.miller@gmail.com> - 2011-05-22 12:37 -0500
Re: Malloc Query Shao Miller <sha0.miller@gmail.com> - 2011-05-22 13:02 -0500
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-22 14:12 -0400
Re: Malloc Query Shao Miller <sha0.miller@gmail.com> - 2011-05-23 03:06 -0500
Re: Malloc Query luser- -droog <mijoryx@yahoo.com> - 2011-05-23 00:42 -0700
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 11:10 -0400
Re: Malloc Query Keith Thompson <kst-u@mib.org> - 2011-05-23 09:06 -0700
Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-22 23:18 +0100
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-22 19:18 -0400
Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-23 11:22 +1200
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 01:57 -0400
Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-23 19:24 +1200
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 14:20 -0400
Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-24 07:41 +1200
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 16:24 -0400
Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-24 09:20 +1200
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 18:05 -0400
Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-24 10:37 +1200
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 19:34 -0400
Re: Malloc Query "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-23 17:48 -0700
Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-24 12:56 +1200
Re: Malloc Query James Kuyper <jameskuyper@verizon.net> - 2011-05-24 07:19 -0400
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-24 11:32 -0400
Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-23 01:04 +0100
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 02:36 -0400
Re: Malloc Query luser- -droog <mijoryx@yahoo.com> - 2011-05-23 00:39 -0700
Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-23 14:44 +0100
Re: Malloc Query Seebs <usenet-nospam@seebs.net> - 2011-05-23 15:16 +0000
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 11:41 -0400
Re: Malloc Query David Thompson <dave.thompson2@verizon.net> - 2011-06-01 16:33 -0400
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-19 18:34 -0400
Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-20 02:36 +0100
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-20 12:26 -0400
Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-20 23:32 +0100
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-20 21:17 -0400
Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-21 14:30 +1200
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-21 11:13 -0400
Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-22 08:50 +1200
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-21 20:03 -0400
Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-22 13:23 +1200
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-22 10:01 -0400
Re: Malloc Query "io_x" <a@b.c.invalid> - 2011-05-26 08:12 +0200
Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-26 19:16 +1200
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-26 15:03 -0400
Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-27 09:16 +1200
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-26 17:55 -0400
Re: Malloc Query "io_x" <a@b.c.invalid> - 2011-05-27 05:47 +0200
Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-26 15:02 -0400
Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-18 22:31 +0100
Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-18 23:37 +0100
Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-19 01:50 +0100
Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-19 02:50 +0100
Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-19 12:14 +0100
Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-19 15:10 +0100
Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-19 15:48 +0100
Re: Malloc Query cri@tiac.net (Richard Harter) - 2011-05-18 19:31 +0000
Re: Malloc Query Ike Naar <ike@iceland.freeshell.org> - 2011-05-18 21:43 +0000
Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-18 22:58 +0100
Re: Malloc Query Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-17 14:01 -0600
Re: Malloc Query Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> - 2011-05-17 13:21 -0700
Re: Malloc Query BGB <cr88192@hotmail.com> - 2011-05-17 14:08 -0700
Re: Malloc Query Michael Press <rubrum@pacbell.net> - 2011-05-17 19:49 -0700
Re: Malloc Query Lauri Alanko <la@iki.fi> - 2011-05-18 00:50 +0000
Re: Malloc Query Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-17 21:21 -0400
Re: Malloc Query "io_x" <a@b.c.invalid> - 2011-05-18 19:31 +0200
Re: Malloc Query Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-18 21:36 +0000
Re: Malloc Query Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-18 21:26 -0400
Re: Malloc Query Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-19 02:07 -0700
Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-19 21:13 +1200
Re: Malloc Query Nobody <nobody@nowhere.com> - 2011-05-18 07:08 +0100
Re: Malloc Query David Resnick <lndresnick@gmail.com> - 2011-05-19 07:51 -0700
Re: Malloc Query Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-19 09:12 -0600
csiph-web