Mark Mitchell <[EMAIL PROTECTED]> 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.
I'm not sure. Users of POOMA may not think of themselves as template meta-programmers, but they certainly (ought to?) want the compiler to do well with meta-programming; otherwise, their programs won't work very well. And because all the interesting work happens when they compile their programs (not when the library is built), I'd say the library authors and the users of those libraries are pretty well aligned. In the same way, with KDE, both the developers of the library and the developers of applications using the library are in the OO camp, and there's relatively little template meta=programming.
Certainly, this is a sliding scale; a lot of programs are somewhere in between, and have components of both, and so forth. I'm not trying to claim some kind of absolute dichotomy.
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.
Definitely true.
I don't think any of this is contrary to what I intended to be my main point, which was that both kinds of usages matter and that neither is outside the maintstream of C++ development.
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 oppposed to improving the inlining heuristics for 4.0, if we can do so relatively safely.
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".
I agree. Personally, I'm not all that concerned about compilation time at -O2 or -O3. It's nice to have the compiler go fast, and it's important not to have unthrottled quadratic algorithms, but, yes, when you ask for optimization you should be willing to pay with compilation time. I do want the compilation time to be proportionate (in a non-mathematical sense) to the benefit.
My concern is not along those lines; I just want to see the patches benchmarked thoroughly, so that we're sure these patches really help, not just a few test cases, but a relatively representative set of applications. And, as others have suggested, we want to find the place (if it exists) where 10% of the compile-time penalty gets 90% of the run-time win.
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.
Entirely possible.
-- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
