Hello, while trying to submit bugreport about regression in compile-time, I've found interesting fact, that while not-preprocessed file regress on every optimization level about 10, 20 and 30% (for -O0, 1, 2) in comparison with 3.4.1, I'm not able to duplicate such regression while using preprocessed file. A comparison table looks: Not preprocessed file: File 341-O0 350-O0 Delta% 341-O1 350-O1 Delta% 341-O2 350-O2 Delta% basic_seq.cc 3.77 4.21 -10.45 3.98 4.99 -20.24 3.82 5.72 -33.22 File preprocessed by GCC 3.4.1: File 341-O0 350-O0 Delta% 341-O1 350-O1 Delta% 341-O2 350-O2 Delta% basic_seq.cc 3.69 3.31 11.48 3.91 3.47 12.68 3.78 3.65 3.56 File preprocessed by GCC 3.5.0: File 341-O0 350-O0 Delta% 341-O1 350-O1 Delta% 341-O2 350-O2 Delta% basic_seq.cc 4.61 4.15 11.08 5.28 4.83 9.32 5.62 5.57 0.9 3.5.0 is from 20040830. Whole report to gcc@ mailing list can be found here:http://gcc.gnu.org/ml/gcc/2004-09/msg00100.html I will attach all needed file here too. Karel
Created attachment 7042 [details] File basic_seq.cc preprocessed by GCC 3.4.1
Created attachment 7043 [details] File basic_seq.cc preprocessed by GCC 3.5.0
Created attachment 7044 [details] Not preprocessed basic_seq.cc file This file is intended for comparison with both preproceesed files, to find out what's going wrong with this issue, i.e. why 3.5.0 is faster on all optimization levels while compiling preprocessed files in comparison with 3.4.1 and why it is slower for compiling not-preprocessed file on all optimization levels.
Karel, To fully reproduce this, we need all the header files needed to preprocess basic_seq.cc ourselves. Would you please attacch them?
Subject: Re: Strange compile-time regression either in cpp or libstdc++ against gcc3.4.1 Sure! They are attached. Karel
Created attachment 7062 [details] include.tar.bz2
Subject: Re: Strange compile-time regression in cpp against gcc3.4.1 Paolo, I would just like to ask if you are really sure that this is preprocessor related and so changing component from libstdc++ to preprocessor is right, especially when I simply preprocess files by -E and measure the same time spent by 3.4.1 and 3.5.0 preprocessors... (0.26 second spent by 3.4.1 and 0.27 spent by 3.5.0) Thanks, Karel
Subject: Re: Strange compile-time regression in cpp against gcc3.4.1 Of course libstdc++ cannot have anything to do with a compile-time regression since it is *not* used at all!
To be clear: libstdc++ is a *runtime* library, not a part of the compiler proper (like libcpp, for instance). Of course C++ applications eventually link it and of course the library may grow bigger and the link itself can become slower. But definitely this cannot be considered a library bug: the libstdc++ category is for bugs of the library proper.
Paolo, I don't understand. libstdc++ headers are brought in by #include directives. It looks like in 3.5 more stuff is included, and the difference results in 10% of compile-time difference. Now, when the file is already preprocessed, CPP really has to do nothing but tokenize the stream. I do not understand why you think this to be a CPP bug. Would you care explaining?
Subject: Re: Strange compile-time regression in cpp against gcc3.4.1 Paolo, thanks for your explanation, but I see possible way how libstdc++ may affect c++ compile-time performance, the way is that it may use much complicated macros evaluation and so hitting cpp performance, not talking about the fact that include files might be just bigger. The problem is that when testing cpp performance separately, I see nearly the same results, so certainly both preprocessor are good and speedy in saving ii files. My guess is that the problem migt be somewhere between 3.5.0's cpp and cc1plus, i.e. data transfer, but not knowing anything about gcc's internals this is just wild guess... Karel
I have no idea whether cpp is involved or not... Probably it's not, as you are saying. I have only removed the wrong categorization libstdc++ which is certainly wrong, since it's used for bugs in the library. Please notice that I have *not* confirmed the bug!
Subject: Re: Strange compile-time regression in cpp against gcc3.4.1 Giovanni, I'm afraid Paolo is right that this is not libstdc++ bug, especially when -E comparison are nearly the same and difference in line numbers count of preprocessed files is just minor: $ ~/usr/local/gcc3.4.2/bin/c++ -time -I../include -time -O0 -Wall -DPIC -fPIC -E basic_seq.cc|wc -l # cc1plus 0.25 0.03 46477 $ c++ -time -I../include -time -O0 -Wall -DPIC -fPIC -E basic_seq.cc|wc -l # cc1plus 0.27 0.03 47680 $ Karel
Subject: Re: Strange compile-time regression in cpp against gcc3.4.1 pcarlini at suse dot de wrote: > I have no idea whether cpp is involved or not... It is not, because it can be reproduced with .ii files, where the preprocessed is not even invoked. > it's not, as you are saying. I have only removed the wrong > categorization libstdc++ which is > certainly wrong, since it's used for bugs in the library. Please > notice that I have *not* confirmed the bug! The *only* difference between the two preprocessed files is libstdc++. Let's say for a moment that, for some absurd reason, including <iostream> in 3.5 brings into scope 4000 new instantiations that where not present in 3.4. This would cause a compile-time regression for any program including iostream. How would you mark such a bug, if not with libstdc++? There is only one data point in this bug: including libstdc++ from 3.5 causes *at least* 10% compile-time regression compared to libstdc++ from 3.4. Now, either the new libstdc++ exploits by mere chance some special bottleneck in the compiler while the old libstdc++ didn't, or the code itself is slower to compile for some reason. This is kind of hard to analyze and surely an interesting issue (the regression is enough to totally destroy the compile-time improvements that the tree-ssa folks brought to us), so I would appreciate some help, and not only something like "please this is not my bug, go away". Giovanni Bajo
As shown the preprocessed file has got faster with 3.5.0 so it cannot be cpp at all.
I should also note the numbers come with repsect with 3.5.0 preprocessed source and 3.4.0 preprocessed source on both compilers so we see that 3.5.0 is faster on both preprocessed source so even the C++ front-end is slower.
IMO the comparison itself doesn´t make much sense, since current mainline is using mt_allocator by default, while 3.4.1 uses the new-based allocator: FWIW, this difference explains the increased size of the pre-processed source but in general compiling and linking a testcase preprocessed with 3.4.1 with current mainline doesn´t make much sense...
Subject: Re: Strange compile-time regression in cpp against gcc3.4.1 pcarlini at suse dot de wrote: > IMO the comparison itself doesn´t make much sense, > since current mainline is using mt_allocator by default, while 3.4.1 > uses the new-based allocator: FWIW, this difference explains the > increased size of the pre-processed source but in general compiling > and linking a testcase preprocessed with 3.4.1 with current mainline > doesn´t make much sense... Well, it would not if the compiler behaved almost the same, as I would have expected. A 10% difference means that either the mt_allocator is too slow to be compiled for some reason, or that the frontend is too slow on it and it should not. Is there a way to set the new-based allocator as default in 3.5? Even a temporary patch Karel can try. If switching back to the new-based allocator in 3.5.0 gets the performance back, at least we would have isolated the problem. Giovanni Bajo
Yes, Giovanni, I agree that this kind of test is worth doing. Just passing --enable-libstdcxx-allocator=new at configure time suffices. The viceversa would be also useful, that is, passing --enable-libstdcxx-allocator=mt to 3.4.1 configure. However, again, please remember that the user, in general, is *not* supposed to preprocess with 3.4.1 and compile/link with 3.5.0 (or much more generally, use an allocator type at pre-processing time and a different one at compile/link time), *very* bad things can happen... ;) Also, please consider that mt_allocator is more complex and *is* expected to be more challenging for the compiler: its performance are *much* better, no free lunch... ;)
Subject: Re: Strange compile-time regression in cpp against gcc3.4.1 As Paolo suggested, I have tried to use new based allocator and configure gcc with --enable-libstdcxx-allocator=new. Results are: File 341-O0 350-O0 Delta% 341-O1 350-O1 Delta% 341-O2 350-O2 Delta% basic_seq.cc 3.78 3.60 5.0 4.01 3.76 6.6 3.92 4.01 -2.2 which looks like --enable-libstdcxx-allocator=new is a good candidate for a fast C++ compilations. :-) I hope I will be able to test it on a full orb directory to see all results. Cheers, Karel
So can we close this as not to be fixed as it is new allocator which is causing the problem (which is runtime improvement)?
Yes, Andrew, we cannot do anything about this.
Subject: Re: Strange compile-time regression in cpp against gcc3.4.1 Sure, close it! 4.0.0 is enough faster anyway! :-) Cheers, Karel
Ok ;)