On inlining in C++

[Matthias Benkmann]

On 05 Aug 2003 08:39:39 +0100 Richard Sandiford <rsandifo@redhat.com>
wrote:

> I'd have thought the burden was (almost entirely) on the people
> defending g++'s current behaviour.  Suppose that, as an experiment,
> someone changes g++ to interpret inline in the "traditional"[*] way.
> And then someone shows that this leads to worse performance for program
> X on target Y.  I don't think we can then say that the compiler is right
> to behave is it does now.  Perhaps whoever wrote program X didn't care
> about the performance on target Y, or perhaps s/he simply used "inline"
> poorly.

I don't think this will happen.

> Both are possible, and it's not the sort of thing you're going to get
> from a simple statistical analysis 

I think that statistics is fine to resolve this, but I suggest a different
statistical measure. We've had lots of complaints about GCC not inlining
well (and in the cases I remember it was always that GCC didn't inline a
function the programmer wanted to be inlined, never the other way around).
If the new strategy results in fewer complaints, it is good.

GCC's technical qualities are irrelevant IMHO. "Customer" satisfaction is
the only thing that counts. A GCC that optimizes well in 90% of cases and
produces lots of complaints due to the remaining 10% where it is abysmal,
is not as good as a GCC that optimizes well in 10% of cases and doesn't
produce complaints because in the other 90% of cases it performs
adequately.

One thing that is often overlooked is that most programs written today
(for desktop platforms, not embedded systems!) do not need inlining
optimization AT ALL. All of the programs I've written so far perform
adequately regardless of whether I compile them with -Os, -O1, -O2 or -O3,
-finline-functions, -whatever. The importance of optimization is vastly
overrated. There are very few applications for which optimization makes a
major difference (e.g. software MPEG-decoders). And these applications are
usually carefully examined and maintained by capable people. These people
should have a portable way of making their own inlining decisions. These
are the people who complain if they can't do so. These are the people who
complain if a new GCC version has a regression in the automatic inliner.
These are the people GCC should be optimized for.

The vast majority of developers won't notice the difference either way.
But even they will be more happy if they look at the assembly of their
compiled program and see that the compiler has inlined the functions they
declared inline. It gives them the reassuring feeling that they are in
charge. Maybe the inlining decision was bad for the cache, but who cares
if the program (like most applications) has to wait for network, disk or
user most of the time or spends most of its time in a system library
(maintained again by the capable people mentioned above)?

MSB

-- 
Ask a silly person, get a silly answer.