Re: Inlining and estimate_num_insns

["Giovanni Bajo" <giovannibajo at libero dot it>]

Mark Mitchell <mark@codesourcery.com> wrote:

> 1. The C++ community has split into two sub-communities.  One is very
> heavily focused on template metaprogramming.  The other is doing more
> "traditional" object-oriented programming.

I would postulate that most of the times the former group are those writing
*libraries*, and the latter group is those using the libraries to produce
applications.

> The kinds of programs
> written by these two communities are drastically different, even
> though, obviously, there is overlap between the two, mixed programs,
> etc.  But, programmers in one camp tend to think that their style is
> "very common" while that of the other camp is "fancy" or
> "complicated".  The truth is that both are now mainstream uses of
> C++, and we need to try to work well with both kinds of code.

Let's remember also that template metaprogramming is used in v3 itself (and
much more so when TR1 is fully merged), in Boost, in UBLAS, and many other
libraries. There are thousands of applications which are written in the
traditional object-oriented paradigm, and still make heavy use the above
libraries.

> 2. I don't think we should be make any changes at this point without a
> relatively comprehensive benchmarking effort.  That means more than a
> few programs, compiled on multiple architectures, with measurements of
> both compile-time and runtime performance.  I'd suggest that tramp3d
> is fine, but I'd also suggesting looking at KDE, Boost, and
> libstdc++-v3. I'd try to measure total compilation time, total code
> size, and some measure of performance.  (Since C++ inlining should
> generally -- but not always, of course -- result in smaller code due
> to removal of calls, code size is probably a rough proxy of
> performance.)

Richard showed already how his patches help on some of the benchamarks you
suggested. They also fix a regression since 3.4 was so much better in this
regard. Of course, compilation time goes up somehow because we are doing more
work now, but the compile time *regression* is probably because of something
else and is merely uncovered by Richard's patches. We also got reports from
other people saying that Richard's patches help.

I'm not sure we should hold such a patch to save a few percent of compilation
time at -O3. -O3 (compared to -O2) means "try to inline harder". Richard's
patches are doing exactly that. I'm sure who uses -O3 doesn't mind us doing
better what we are asked for. And if compilation time is critical for them,
they can still use -O2.

Also, I would like to see detailed reports of where the compilation time goes,
after the patch. I'm sure we can go blaming other optimizers (probably some of
the new ones) for the compile time regression.

Giovanni Bajo