On Monday 28 February 2005 01:46, Giovanni Bajo wrote: > 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.
And it may introduce new ones. > Of course, compilation time goes up somehow because we are doing > more work now, Your definition of "somewhat" is really off. From Richard's mail (http://gcc.gnu.org/ml/gcc/2005-02/msg01073.html): PR8361 -O3 compile times are 3.4 25s 4.0 20s 4.0 patched 31s Now, let me see... Hmm... 11s slowdown on 20s, that is more than 50%. If that is "somewhat" and "a few percent" for you, then I don't want to know what you consider to be a serious compile time slowdown ;-) > but the compile time *regression* is probably because of > something else and is merely uncovered by Richard's patches. Probably, but we don't know that, now do we? So we need to figure that out first, instead of being all emotional over this. If you look at the graph Richard made (find it here: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01608.html), and at the measurements he presented in another mail, it's obvious that the new heuristics he proposes give *smaller* estimates than 3.4. Part of the slowdown may be in there as well. And maybe the inline limits are too *high* after Richard's patch. The patch needs to go though a whole new process of tuning, and that takes time. This patch could be very destabilizing for GCC 4.0, so we *have* to be careful, and know what effects the patch will have on normal code (ie. not the heavily templatized C++ that you seem to love and I definitely hate so much). If you have a problem with that, and this is such a big deal for you, maybe you should ask yourself "Why did I not complain about this problem long ago, months before branching GCC4". Because you work on and with GCC a lot, and I haven't heard you complain about this before. > I'm not sure we should hold such a patch to save a few percent of > compilation time at -O3. Explain that to the many users who have complained about compile time problems in the past. Like Karel Gardas for example. I don't recall him saying he had performance problems with GCC 4.0, but he definitely had some problems with compile time issues. And there are many like him. > -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. These heuristics affect -O2 compile times just as well. > Also, I would like to see detailed reports of where the compilation time > goes, after the patch. That would be nice yes. But... > I'm sure we can go blaming other optimizers > (probably some of the new ones) for the compile time regression. ...it is unlikely that putting the blame somewhere will magically make those perceived problems go away. I can only wonder why we are having this discussion just after GCC 4.0 was branched, while it was obvious already two years ago that inlining heuristics were going to be a difficult item with tree-ssa. Gr. Steven
