Nearly two years ago, a great debate was begun on this mailing list about when to inline code and when not to, as well as the actual merits of inlining in the first place. I will attempt to summarize here, becuase this debate was never concluded and we now are at a point where some things are inlined, and some other things are bogusly marked as inline but are not actually usable as such (did that sentence make sense?).
This is my attempt to paraphrase the discussion. I'm just laying it out as I understand it, so if I misinterpret somebody please forgive me. John Tobay started off the whole thing by suggesting that all internal Parrot functions are declared inline (meaning with the "inline" keyword where supported), with any external API functions existing as wrappers that "call" the equivalent inlined function. [Question: At least on GCC, inline funcs can be external, and don't have to be static, true? If true, why have a wrapper func at all? My understanding is that inline funcs will be inline but an extern version will also be generated in that case.] He alluded to using a preprocessor (which I believe was a popular idea at the time) to generate these wrappers. Simon Cozens referenced Sapphire as an example of the advantages of this approach. Some discussion was raised about premature optimization. That thread didn't seem to go anywhere though; the arguments toward future flexibility (tied into the preprocessor idea) seemed to win out. Dan Sugalski expressed his wish to be able to squish all the Parrot source into a monster .c file, to let the compiler do the most amount of magic possible. He also mentioned a point brought up later (and louder) by Nick Ing-Simmons that inline may not help at all. Nick also states that most modern compilers can intelligently decide whether or not to inline functions in the first place. At this point there was some discussion about the differences between using a macro to inline code or using the "inline" keyword where supported and letting the compiler do it. It was generally agreed that macros for this purpose are Bad, many reasons being cited (included in those were some pretty gross Perl5-isms). It was also generally agreed that neither the caller or the compiler should not be forced to inline or not inline anything. Whether or not GCC's inline keyword was treated as a hint or an order was not made clear, and no-one mentioned other platforms (MSVC comes to mind) that support inline. Nick I-S summarized his views as follows (here I use a direct quote becuase he was most efficient): > >So aren't we all saying the same thing? > > I don't think so - it is a question which way we code the source: > > A. Use 'inline' every where and trust compiler not to do what we told it > if it knows better. > B. No inline hints in the source and trust the compiler to be able to > do the right thing when prodded with -O9 or whatever. > C. Make "informed" guesses at to which calls should be inlined. > > My view is that (B) is the way to go, aiming for (C) eventually, because > (A) gives worst-case cache purging. To which Tobey replied: > Moving from a first-guess (C) to an optimal (C) (where we make > reasonable hints all the time, no doubt with the aid of some Configure > tests or machine-dependent conditionals) can be an ongoing pursuit. He did not elaborate on the means through which this would happen. Nick expressed "Nick's performance theory" as follows: > I have said this before but the gist of the Nick-theory is: > > Page boundaries are a don't care unless there is a page miss. Page > misses are so costly that everything else can be ignored, but for sane > programs they should only be incured at "startup". (Reducing code size > e.g. no inline only helps here - less pages to load.) also stating: > ...I _fundamentally_ believe inlining is nearly always sub-optimal for > real programs. > > But -O3 (or -finline-functions) is there for the folk that want to > believe the opposite. > > And there is -Dinline -D__inline__ for the inline case. What there isn't > though is -fhash_define-as-inline or -fno-macros so at very least lets > avoid _that_ path. At which point a technical discussion ensued involving page faults and TLBs, and L1 and L2 cache latency and penalties, not really resulting in any policy decisions but surely enlightening many of us. ....and then the discussion seemed to burn itself out... just when it was getting good! Believe it or not, most of this took place over just a couple days. But that still leaves us with an INLINE macro that seems to be largely irrelivant due to the fact that, in order to be useful, inlined functions have to be defined in the same module that uses them. So the question boils down to this: Do we use "inline", or not? Note that (in my estimation) a "yes" answer should NOT mean "smear the place with INLINE"; instead it should mean that we use it judiciously where it seems to give a performance boost. Have a nice day. - D <[EMAIL PROTECTED]>
