Use pragma INLINE or not?

Use pragma INLINE or not?

[Fred Stluka]

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-7236

Re: Use pragma INLINE or not?

[Orville R. Weyrich]

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)
--------------------------------------           ******************************

Re: Use pragma INLINE or not?

[Robert I. Eachus]

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...

Re: Use pragma INLINE or not?

[Brian Hanafee]

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

Re: Use pragma INLINE or not?

[George C. Harrison, Norfolk State University]

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 ---------------------------------

Re: Use pragma INLINE or not?

[Jim Showalter]

>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++.    *

Re: Use pragma INLINE or not?

[Robert Firth]

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.

Re: Use pragma INLINE or not?

[Michael Feldman]

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

Re: Use pragma INLINE or not?

[Kenneth B. Hawks]

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....

Re: Use pragma INLINE or not?

[Lance E Murray]

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).

Re: Use pragma INLINE or not? (SUMMARY)

[Fred Stluka]

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-7236