Re: On inlining in C++

[Mike Stump <mrs at apple dot com>]

On Tuesday, August 5, 2003, at 01:25 AM, Gabriel Dos Reis wrote:
> If people want, we can bump up the numbers
>
> It it a matter of bumping numbers.

Ok, submit numbers for a testcase, before the change, a suggested 
change, and numbers after...  I think it is productive if we bump up 
the number, not to 4233153983 from a previous of 300, but rather to 
another number such that your testcase gets 95% of the benefit you see 
to switching to a number like 4233153983 and for all lower numbers, the 
you get <95% of the improvement.


For example:

n	time
300	500.0
310	492.0
320	492.0
350	491.0
380	490.0
392	489.0
393	460.0
400	460.0
410	461.0
500	459.0
1000	459.2
3000	458.0
...

So, instead of picking 3000, as the best, we pick 393, as then we get 
most of the benefit, maybe not all, but most.  I'd ask that the 
testcase be real code, or abstracted from real code, not purely 
invented to move the numbers.

Also, any such change should be weighed against real code, SPEC, a 
boost or something like it benchmark and so on...  plus anything else 
people would like to run against.

For example, some numbers were put in for C++ because of odd template 
code, where everything is marked inline but, we don't want to explode 
things, but these same number probably hurt C inlining performance.  
I've not seen too many people complaining that C inlines too much (well 
other than indirectly about -O3, which we can discount as a factor for 
some types of changes), and have seen lots of people complaining that C 
inlines too little, so, bumping up some of the numbers for C, easily 
makes sense.

Likewise, even for C++, we should be happy to experiment some with the 
numbers and collect feedback on those experiments and _then_ make an 
informed choice on what the numbers are.

My hope is that we can globally improve the choices the compiler makes 
by default, not just for any one testcase.

I'd rather have a debate that tuning the defaults for KDE speed is 
slightly more important than tuning for raw SPEC speed, as SPEC people 
have ways to get the right numbers into the compiler.  Or that tuning 
for boost is more important than tuning for <name of some other random 
C++ project>...

Also, we could discuss, should this tuning parameter be used in this 
case or should this other parameter be used (or invented), for example, 
for methods contained textually inside a class, should we use the same 
parameter as functions marked inline in C or...  Here is where I'd love 
your feedback.

If you are the only one to submit numbers, then you might be able to 
move any of the numbers anyway you want.  If others don't like such a 
movement, sooner or later someone is going to have to submit numbers, 
and then we might have to revisit the issue.

I don't want you to feel like you are loosing, or that the compiler 
isn't doing the best that it can.  I'd rather empower you to tell us 
the performance you see, and ask for a change of default, or ask for 
improvements in the underlying algorithms; then based upon all that we 
hear from everyone, the maintainers are going to have to just make the 
best choices they can.  The process should be open, honest and 
reflective of the needs of users.

If that sounds reasonable, let's do it, if it doesn't, ignore me...  :-)