Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!apple!amdahl!dgcad!gary
From: gary@dgcad.SV.DG.COM (Gary Bridgewater)
Newsgroups: comp.lang.c++
Subject: Re: inline policy
Message-ID: <1218@svx.SV.DG.COM>
Date: 10 Nov 89 09:58:39 GMT
References: <1520008@hpmwjaa.HP.COM> <1520010@hpmwjaa.HP.COM> <28966@shemp.CS.UCLA.EDU>
Reply-To: gary@svx.SV.DG.COM ()
Organization: Data General SDD, Sunnyvale, CA
Lines: 67

In article <28966@shemp.CS.UCLA.EDU> rjc@cs.ucla.edu (Robert Collins) writes:
>In article <1520010@hpmwjaa.HP.COM> jeffa@hpmwtd.HP.COM (Jeff Aguilera) writes:
>>As Gary Bridgewater fell off the deep end, he wrote:
I was pushed.
>>If you really want such fine control over your application, then program in
>>assembly, not C++.  The world will be a better place.
I used to and the world is pretty much as it was.
>>You are sure arrogant.  Since inlining involves various tradeoffs, good
>>engineering practice should dictate the decision whether a particular idiom
>>is inlined or not.  A self-centered programmer who covets every line of
>>his code and inlines for any damn reason is obviously not intelligent enough
>>to decide.
Petulant perhaps, but not arrogant. I don't advocate big inlines just the
freedom to have them. In a language full of concepts  having to remember
what I can and cannot inline seems an unnecesary burden. Programming practices
are a matter of policy and tools don't - or shouldn't - try to make policy.
Detroit doesn't make cars that will only go 55MPH (65 on Interstates).

>You should apologize to Gary too, IMHO.  I think you both should just
>relax a little!  Put a few smileys in your articles!  :-) :-) :-)  Gosh,
>I feel better already.  Try it! ;-)
I must apologize to the person I was originally replying to - I missed the
point of his posting. I don't feel I am owed one. This is almost a religious
topic and I expected some amount of disagreement. Ok - :^}

>Ok, let's talk about inlining.  I think you both are right, although I
>also think you both go a little overboard.  Inline functions are good
Again - I was pushed.
>for two things (1) avoiding function call overhead and (2) procedural
>integration (optimization). 
3) concentrating platform specific code as opposed to zillions of
   embedded #ifdef's,
4) building powerful "verbs" to allow inherently complex code to be more
    easily understood in a safer, more controlled manner than #defines,
5) as a surrogate for private functions such as is found in PL/1 or Pascal.
to name a few more.
>... An optimizing compiler has the potential to do a whole lot
>more when it can actually see all the code that is to be executed. ...
A good point - especially on RISCs.

>Now, I don't intend to imply that *every* function should be inlined.
Exactly
>I want the compiler to help me out.  I will help it, by telling it I
>think the resulting program might benefit if a given function were
>expanded inline.  I want it to help me by evaluating the costs/benefits
>of inlining each occurance of the function.  And I don't mean the
>current strategy of simply counting the number of instructions to
>implement the `standalone inlinable function'.  The evaluation has to
>take into account the *net* increase/decrease in code size that will
>result.  Now, I realize that this is a very hard problem to do well,
>especially for a C++ `compiler' that produces C as the target language.
>That is ok, though, because the last thing we want is bored, unchallenged
>compiler-writers, right? :-)
Yes - inlining for performance will be much more interesting with c++
compilers that generate native code. Now we get back to coding c++ like
it was assembly language. Why is that so abhorrent? Coding in assembler
on RISC systems is not very simple and not at all easy to maintain w.r.t.
optimization.
So, I agree that at some unspecified future date - soon, I hope, the
compiler will be spiffy enough to decide what the right thing really is
to do for inlining based on performance metrics. That time is not now
however, so I want to be able to do it. Again - that is not the same as
saying I want to do it and far from saying I want to do it all the time
to the detriment of maintainability, clarity or sanity. I don't even
want to know of an obsfucated c++ contest much less enter one.
-- 
Gary Bridgewater, Data General Corporation, Sunnyvale California
gary@proa.sv.dg.com or {amdahl,aeras,amdcad}!dgcad.SV.DG.COM!gary
Shaken but not stirred.