Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #87150

Re: I was wrong about gcc's inlining behavior

Show all headers | View raw

Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:
> In fact the effect of inlining is only that large because the calling 
> convention is inefficient at least on x86/x64.

The original "classical" reason for inlining in the distant past was that
it would avoid an extra function call, which adds many clock cycles.
However, that's not the reason why inlining makes code faster nowadays.
Function call overhead is extremely small, even inconsequential in most
cases.

By far the main reason why inlining makes code faster nowadays, especially
in number-crunching code, is that it allows the compiler to optimize the
calling code with things like auto-vectorization. A function call (that
doesn't get inlined) in a tight inner loop acts effectively as an
optimization barrier: The compiler can't see what the function is doing
and can't do autovectorization, move things around, etc. (For example,
if the function reads some value from an array, if the compiler can
inline that read, it will help it optimize those array accesses.)

>> It appears that gcc uses a different inlining strategy when dealing
>> with local and global functions (that have no 'inline' keyword).
> 
> I guess it does for good reasons.

Well, it's enormously inconvenient. Having your number-crunching class
become almost twice as slow just because you did some refactoring and
cleaning up (that shouldn't affect is performance) is annoying. (Good
thing I actually had a benchmark and noticed.)

I really had to go my way to make as many functions 'inline' as I
reasonably could, moving some of the function implementations to the
header, making others private (so that they could be declared 'inline'
in the source file), and so on. Even then I had to compromise by
having the class become about 20% slower (in order to avoid
excessive amounts of code in the header file). Really annoying.

Back to comp.lang.c++ | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

I was wrong about gcc's inlining behavior Juha Nieminen <nospam@thanks.invalid> - 2022-10-21 11:44 +0000
  Re: I was wrong about gcc's inlining behavior Michael S <already5chosen@yahoo.com> - 2022-10-21 07:01 -0700
    Re: I was wrong about gcc's inlining behavior Juha Nieminen <nospam@thanks.invalid> - 2022-10-24 06:45 +0000
      Re: I was wrong about gcc's inlining behavior Michael S <already5chosen@yahoo.com> - 2022-10-24 10:11 -0700
        Re: I was wrong about gcc's inlining behavior scott@slp53.sl.home (Scott Lurndal) - 2022-10-24 17:54 +0000
  Re: I was wrong about gcc's inlining behavior Bo Persson <bo@bo-persson.se> - 2022-10-21 16:41 +0200
  Re: I was wrong about gcc's inlining behavior Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-10-21 08:47 -0700
    Re: I was wrong about gcc's inlining behavior scott@slp53.sl.home (Scott Lurndal) - 2022-10-21 16:04 +0000
  Re: I was wrong about gcc's inlining behavior Marcel Mueller <news.5.maazl@spamgourmet.org> - 2022-10-22 09:21 +0200
    Re: I was wrong about gcc's inlining behavior scott@slp53.sl.home (Scott Lurndal) - 2022-10-22 15:05 +0000
    Re: I was wrong about gcc's inlining behavior Juha Nieminen <nospam@thanks.invalid> - 2022-10-24 07:00 +0000

csiph-web