stluka@neptune.software.org (Fred Stluka) (06/19/91)
About the use of pragma INLINE...
There seem to be 2 schools of thought:
1) Don't use it. Smart compilers will automatically
inline the most appropriate routines.
2) Use it. Compilers aren't that smart yet.
What do you think?
Please POST votes accompanied by supporting arguments.
Or MAIL simple YES/NO votes to me. I will summarize.
Thanks,
--Fred
--
Fred Stluka Internet: stluka@software.org
Software Productivity Consortium UUNET: ...!uunet!software!stluka
2214 Rock Hill Rd, Herndon VA 22070 USA Phone: (703)742-7236orville@weyrich.UUCP (Orville R. Weyrich) (06/19/91)
In article <1991Jun18.171459.11744@software.org> stluka@neptune.software.org (Fred Stluka) writes: >About the use of pragma INLINE... > >There seem to be 2 schools of thought: > > 1) Don't use it. Smart compilers will automatically > inline the most appropriate routines. > > 2) Use it. Compilers aren't that smart yet. > >What do you think? > 3) Use it if you think that you have the time and ability to do a better job than the compiler of sub-optimizing the code. -------------------------------------- ****************************** Orville R. Weyrich, Jr., Ph.D. Certified Systems Professional Internet: orville%weyrich@uunet.uu.net Weyrich Computer Consulting Voice: (602) 391-0821 POB 5782, Scottsdale, AZ 85261 Fax: (602) 391-0023 (Yes! I'm available) -------------------------------------- ******************************
eachus@largo.mitre.org (Robert I. Eachus) (06/19/91)
In article <1991Jun18.171459.11744@software.org> stluka@neptune.software.org (Fred Stluka) writes:
About the use of pragma INLINE...There seem to be 2 schools of
thought, what do you think?
Pragmas are supposed to be advice to the compiler, and a good
compiler should NOT ingnore that advice. But there are actually two
separate cases, and I get frustrated by compilers which try to "help"
me when it is inappropriate.
If a procedure or function call is internal to the unit which
defines that subprogram, compilers should inline when obviously
beneficial, and inline in all cases if the programmer requests it.
(Yes, that includes subprograms which may call themselves directly or
indirectly, inline the original call and generate explicit call where
necessary for recursion. In cases of indirect recursion, a programmer
can use pragma INLINE to help the compiler decide where explicit calls
should be put.)
However when a call is to a subprogram exported by another library
unit, a compiler should not inline absent an explicit pragma, since
the programmer may not want the extra dependencies created.
My usual style is to put a commented out pragma INLINEs in the
package specs if I want inlining in the final version, and remove the
comments only for major builds or for a final version. A compiler
option to ignore pragma INLINE would be nice, but very tricky to
implement usefully except on a per library basis. As it is, the
uncommenting is just one of many automatic steps in the process of
doing a build.
--
Robert I. Eachus
with STANDARD_DISCLAIMER;
use STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...bhanafee@deimos.ads.com (Brian Hanafee) (06/19/91)
In article <1991Jun18.171459.11744@software.org>, stluka@neptune.software.org (Fred Stluka) writes: > There seem to be 2 schools of thought: > > 1) Don't use it. Smart compilers will automatically > inline the most appropriate routines. > > 2) Use it. Compilers aren't that smart yet. > > What do you think? 3) "A pragma is used to convey information to the compiler." Use it when you know something about the code that the compiler doesn't know. In the case of case of pragma INLINE, this shouldn't happen very often. It might be appropriate for short library routines (such as math vector operations) which you might expect to find in hot spots such as inner loops. Generally, pragma ELABORATE (unit_you_want_inlined) followed by pragma OPTIMIZE (time) in the calling unit is more appropriate. Brian Hanafee
g_harrison@vger.nsu.edu (George C. Harrison, Norfolk State University) (06/20/91)
In article <1991Jun18.171459.11744@software.org>, stluka@neptune.software.org (Fred Stluka) writes: > About the use of pragma INLINE... > > There seem to be 2 schools of thought: > > 1) Don't use it. Smart compilers will automatically > inline the most appropriate routines. YES!! However, in the LRM (6.3.2) it is written "the pragma INLINE is used to indicate that inline expansion of the subprogram body is D E S I R E D (emphasis, mine) for every call of each of the named subprograms...." Is this action of pragma INLINE required? In paragraph 3 it is written "....an implementation is free to follow or to ignore the recommendation express by the pragma." So... why have it at all? > Thanks, > --Fred > -- > Fred Stluka Internet: stluka@software.org George... -- George C. Harrison (not the lead guitar in the Beatles) --------------- ----- Professor of Computer Science ----------------------- ----- Norfolk State University ----------------------- ----- 2401 Corprew Avenue, Norfolk, Virginia 23504 ----------------------- ----- INTERNET: g_harrison@vger.nsu.edu ---------------------------------
jls@netcom.COM (Jim Showalter) (06/20/91)
>There seem to be 2 schools of thought: > 1) Don't use it. Smart compilers will automatically > inline the most appropriate routines. > 2) Use it. Compilers aren't that smart yet. >What do you think? [Tried to e-mail this, but it bounced...] Let the compiler inline when it can figure it out. Use a profiler to find bottlenecks when tuning the code, and manually inline the offenders. DON'T inline everything to "be sure"--this has a bunch of bad effects, and is completely unecessary (10% of your code uses 90% of your CPU). -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
brett@tle.enet.dec.com (Bevin Brett) (06/20/91)
...
>>There seem to be 2 schools of thought:
...
Pragma INLINE gives a compiler permission to establish a dependency on
a library level compilation unit BODY in order to do the inlining. This
permission is not granted without the pragma.
So the advice is. Don't both if the body is in the same library level unit
as the call, otherwise use if if necessary to give permission for extra
dependencies.
/Bevinfirth@sei.cmu.edu (Robert Firth) (06/27/91)
In article <1991Jun19.234429.20796@netcom.COM> jls@netcom.COM (Jim Showalter) writes: >Let the compiler inline when it can figure it out. Use a profiler >to find bottlenecks when tuning the code, and manually inline the >offenders. DON'T inline everything to "be sure"--this has a bunch >of bad effects, and is completely unecessary (10% of your code uses >90% of your CPU). Ah, how true! I remember writing my very first execution profiler, for a machine that didn't have one. To test it, I profiled a pretty substantial program that I'd writen myself, maintained for a few years, and with which I believed myself reasonably - nay, intimitely - familiar. Well, before profiling, I marked my guess at the top few time sinks - obvious things such as the chain of 6 nested procedure calls it took to emit one byte of output data. All my guesses together accounted for 6% of the time. The number one time sink was a search loop that I'd stupidly written the wrong way round - the item being looked for was usually near the end of the list rather than near the beginning. Who would have believed that mattered for a list of maximum length 18? I reversed the search and saved almost 20% of the time.
mfeldman@seas.gwu.edu (Michael Feldman) (06/28/91)
In article <27847@as0c.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes: [discussion of execution profiling] > >All my guesses together accounted for 6% of the time. The number >one time sink was a search loop that I'd stupidly written the wrong >way round - the item being looked for was usually near the end of >the list rather than near the beginning. Who would have believed >that mattered for a list of maximum length 18? I reversed the >search and saved almost 20% of the time. Thanks for being courageous enough to admit this. Most of us have had similar experiences. In the end, fixing your algorithm paid off far better than micro-tweaking. My students come from all walks of life, including many industry folks. Sometimes it's very hard to convince the latter (especially, sadly, the C hackers among them), that no amount of micro-tweaking can turn an N**2 program into an N log N program. To do the latter requires at least minimal background in algorithms. Too many students bitch about having to study that "irrelevant stuff." And with all the chatter I read about "software engineering education," I see very little in those quarters about the importance of algorithm analysis and theory. People have suggested we should drop it from our curriculum in favor of heavier emphasis on confiugration management. Figure that out. 'Course no amount of algorithm theory could substitute for a careful analysis of the properties of the data you really expect to see, as you discovered, Robert. Thanks for a good perspective on the subject! Mike
hawksk@lonex.radc.af.mil (Kenneth B. Hawks) (06/28/91)
In article <3398@sparko.gwu.edu> mfeldman@seas.gwu.edu () writes: > Stuff deleted. > Too many students bitch about >having to study that "irrelevant stuff." And with all the chatter I read >about "software engineering education," I see very little in those >quarters about the importance of algorithm analysis and theory. People >have suggested we should drop it from our curriculum in favor of heavier >emphasis on confiugration management. Figure that out. > >'Course no amount of algorithm theory could substitute for a careful >analysis of the properties of the data you really expect to see, as you >discovered, Robert. Thanks for a good perspective on the subject! > >Mike It's easy Mike, that's how you spot the hackers from the disciplined developers!!! The hacker keeps coding until they "get it to work", thus the emphasis on Configuration Management. The disciplined software engineer takes the time to take an algorithmic approach , i.e. they design the thing then code it, thus these folks emphasise the disciplines of the architect (to jump into the current on going debate) and don't tax the config mgt system anywhere near as much as the hacker. Before firing them, I've seen hackers try to create 2 or 3 "final" coded modules in a day. (One of my little management indicators). Ken Kenneth B. Hawks |\ /| "Fox Forever" Rome Laboratory, Griffiss AFB, NY ^o.o^ BSA hawksk@lonex.radc.af.mil =(v)= Disclaimer: There is no one else here who thinks like I do; therefore....
stluka@software.org (Fred Stluka) (06/28/91)
As promised, here is a summary of responses I got via e-mail.
In general the e-mailed responses spanned the same range as
the posted ones, with most people agreeing that you shouldn't
INLINE unless you are sure you need to.
In a time-critical environment, where you are *sure* of where
the bottlenecks are, then you can probably do a better job
than the compiler. Otherwise, write all the code without
INLINE, then use a performance analyzer to determine where to
add them for maximum effect.
Other points worth mentioning:
From: gdfwc3!jesmith@texsun.Central.Sun.COM (Jesse Smith)
The VAX/VMS Ada 2.1 compiler switch
/OPTIMIZE=(TIME,INLINE:MAXIMAL)
made code run 20% faster than just:
/OPTIMIZE=TIME
From: Eric_Alan_Christiansen@cup.portal.com
INLINE causes problems during development:
- Obscures code a symbolic debugger, but if disabled
with a command line switch, causes warnings to be
generated, obscuring other more relevant messages.
- Creates dependencies of callers on bodies, not just
specs, forcing more recompilations.
Also, inlining is sometimes desired for a routine when called
by caller A (for speed), but not when called by B (for space
or for reduction in dependencies). INLINE applies always or
never. Compilers may internally do a better job.
Thanks for the input,
--Fred
--
Fred Stluka Internet: stluka@software.org
Software Productivity Consortium UUNet: ...!uunet!software!stluka
2214 Rock Hill Rd, Herndon VA 22070 USA Voice: (703)742-7236gamester@cup.portal.com (Lance E Murray) (06/29/91)
Thanks for the discussion on this topic. As someone who is monitoring a 32K line Ada project (using 1750A) I have ran into this same "mentality" of ..."We don't have time to do analysis, we need to get it coded". Although management wants to use this approach to save critical schedule I've always seen the opposite occur. More time is spent trying to patch the code (and even patch the patches) than doing it right the first time. There seems to be a belief that unless the programmers are coding they are not working. Therefore, with a push towards Configuration Management, those in management can see the different releases and feel secure in the knowledge that the programmers are "working as hard as they can". The education system in this country seems to promote the "keep doing it until it's right" method of software problem solving. There are few, if any classes taught on how analysis should be performed to find what the problems are (i.e, how to fix problem, not symptoms).