Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Uncle Steve Newsgroups: comp.lang.c Subject: Re: Malloc Query Date: Mon, 23 May 2011 14:20:28 -0400 Organization: Friends of the Galactic Collective Lines: 105 Message-ID: <2cc0f0e084f264b-656fa@gmail.com> References: <98a074c87051012-452fb@gmail.com> <0.bf5e9ff46dfbfc1e78d6.20110519032218BST.87tycrsa3p.fsf@bsb.me.uk> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Injection-Info: mx04.eternal-september.org; posting-host="bEfhTN2MIXkiD2rZAL7fMg"; logging-data="14700"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/vxJ83XTYrfbYkA6+7kOUZ" User-Agent: nn 6.7.3 Content-Length: 4387 Cancel-Lock: sha1:JCpphgxyTokrBkQL7V9toICpK8g= Xref: x330-a1.tempe.blueboxinc.net comp.lang.c:4571 On Mon, May 23, 2011 at 07:24:11PM +1200, Ian Collins wrote: > On 05/23/11 05:57 PM, Uncle Steve wrote: > >On Mon, May 23, 2011 at 11:22:57AM +1200, Ian Collins wrote: > >>On 05/23/11 11:18 AM, Uncle Steve wrote: > >>>On Sun, May 22, 2011 at 1u1:18:36PM +0100, Ben Bacarisse wrote: > >>>>Uncle Steve writes: > >>>> > >>>>>On Sun, May 22, 2011 at 02:49:51AM -0700, luser- -droog wrote: > >>>>>> > >>>>>>I've been using integer offsets instead of pointers a lot lately and > >>>>>>I think you might be better off using the array formula explicitly: > >>>>>> > >>>>>> #define arena_obj_addr(x, n) ((void *) (x->arena + n * x->obj_size)) > >>>> > >>>>Everyone is taking chances here. The x and n should be in parentheses > >>>>so that the macro expands as expected. This is one reason why functions > >>>>are usually preferred. > >>> > >>>For a long time I've thought macros were preferable to functions for > >>>the reason that a function call has to save registers, stuff it's > >>>arguments on the > >>>stack, and so on. Macros should just fold into the program text, but > >>>today inline functions are just as fast as macros. It has become a > >>>matter of preference. gcc even has the ability to use register > >>>calling conventions for function calls in some circumstances. The > >>>distinction between a macro and a function call is becoming moot. > >> > >>No it isn't. All the disadvantages of function like macros still exist, > >>but the single (possible) disadvantage of function calls has gone. > > > >Not so fast, Mr. Collins. Macros are useful in numerous situations > >where function calls would be inefficient. > > The only real use for macros is passing __FILE__ and __LINE__ to debug logs! No, not really. > >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. 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? > >Not enough? Is it smart to rely on the compiler to optimize the crap > >out of everything, or is it better to write efficient code at the > >outset? > > Inlining is a very simple optimisation. You also overlook the opposite No it isn't. > 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. > compiler should be able to judge where it is appropriate to inline. > Compilers targeted at embedded devices often have options to tune these > heuristics. Decent compilers for hosted environments offer profile > feedback to further tune optimisations. > > In short, the more choice you give the compiler, the better job it can do. Of course. > >There are a number of C compilers out there that are not gcc, > >and which may or may not generate equivalent code for otherwise > >similar macros/functions. I'm O.K. with peppering my code with > >well-designed macros and ignoring functions for simple common > >procedures, but then I'm biased that way from habit. > > I guess working with C++ for many years has biased me the other way. > Aggressive inlining has long been a feature of C++ compilers. It used > to be a unique feature, but those days are long past. I guess so. In the last twenty years there's been a lot of work on compilers, that's for sure. Regards, Uncle Steve -- Should a professional politician be charged with molestation if he kisses babies while attending political rallies?