This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: On inlining in C++

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]