Bugzilla – Bug 677
gcc cxxflags plays (multiple questions)
Last modified: 2009-10-23 11:48:16 UTC
I have several questions/proposals about compiler flags. I've decided not to create several bugs and keep everything in one place. == First == gcc -g option makes executables 5 times larger in static optimized version. What's the reason in passing -g option to gcc in optimized profile? Is it required for valgrind checks? Of course, it doesn't influence on memory footprint and must not significantly change computation speed. But anyway this debugging information is absolutely useless during long production simulations and only consumes hard drive space. I see 2 ways: 1) add a new profile like "release" without debugging info at all 2) add a new configure option "--enable-strip" to run gcc with -s flag (or equivalent flag for other compilers). == Second == Make wscript pick up environmental variables like CXXFLAGS_EXTRA to append them to automatically assembled CXXFLAGS (this may be useful for some compilation related experiments). == Third == Add gcc "-pipe" option not to create temporary files (this will slightly speed up compilation) (must be supported even under cygwin) == Fourth == Add gcc "-fomit-frame-pointer" option. This will slightly speed up execution (I've got about 1-3% speed up) and reduce code size, but make debugging impossible on several architectures. So I think it is acceptable under "release" profile (from First proposal). == Fifth == Add gcc "-march=native" option. Though it doesn't have any significant performance gains (I think due to intensive memory operations and bad code/data locality), it may be valuable for future models with intensive calculations.
Created attachment 586 [details] Add "release" profile (see == First ==)
Created attachment 587 [details] Add option "--enable-strip" (see == First ==)
Created attachment 588 [details] Respect CXXFLAGS_EXTRA (see == Second ==)
Created attachment 589 [details] gcc -pipe (see == Third ==)
Created attachment 590 [details] gcc -fomit-frame-pointer (see == Fourth ==)
(In reply to comment #0) > I have several questions/proposals about compiler flags. > I've decided not to create several bugs and keep everything in one place. > > == First == > gcc -g option makes executables 5 times larger in static optimized version. > > What's the reason in passing -g option to gcc in optimized profile? > Is it required for valgrind checks? For profiling purposes (cachegrind or memprof, for example), you want your code to be both optimized and also to contain full debugging information. > Of course, it doesn't influence on memory footprint and must not significantly > change computation speed. > But anyway this debugging information is absolutely useless during long > production simulations and only consumes hard drive space. > I see 2 ways: > 1) add a new profile like "release" without debugging info at all > 2) add a new configure option "--enable-strip" to run gcc with -s flag (or > equivalent flag for other compilers). The two ways are mutually exclusive, right? I don't see the point of stripping debug symbols; might as well not produce them in the first place! But I am +1 on your proposed 'release' profile. > > > == Second == > Make wscript pick up environmental variables like CXXFLAGS_EXTRA to append them > to automatically assembled CXXFLAGS (this may be useful for some compilation > related experiments). Meh.. is this really so much useful? What is wrong about using CXXFLAGS env var. to completely override the default flags? > > == Third == > Add gcc "-pipe" option not to create temporary files (this will slightly speed > up compilation) (must be supported even under cygwin) gcc "-pipe", does it really much difference? If it's always so good an option, why doesn't gcc use it by default? > > == Fourth == > Add gcc "-fomit-frame-pointer" option. > This will slightly speed up execution (I've got about 1-3% speed up) and reduce > code size, but make debugging impossible on several architectures. > So I think it is acceptable under "release" profile (from First proposal). +0 (I abstain) > > == Fifth == > Add gcc "-march=native" option. > Though it doesn't have any significant performance gains (I think due to > intensive memory operations and bad code/data locality), it may be valuable for > future models with intensive calculations. > -march=native appears to be a good idea considering that ns-3 is not ever installed or packaged for distributions.
(In reply to comment #6) Thank you for your quick reply! > > What's the reason in passing -g option to gcc in optimized profile? > > Is it required for valgrind checks? > > For profiling purposes (cachegrind or memprof, for example), you want your code > to be both optimized and also to contain full debugging information. Thank you, I understand now. > > I see 2 ways: > > 1) add a new profile like "release" without debugging info at all > > 2) add a new configure option "--enable-strip" to run gcc with -s flag (or > > equivalent flag for other compilers). > > The two ways are mutually exclusive, right? I don't see the point of stripping > debug symbols; might as well not produce them in the first place! Yes, I see no reason in implementing them both. I like the first way more too, because it allows to add some other flags, that may conflict with profiling, for example. The second way is just an alternative. And I know some packages behaving that way (compile with -g3 -ggdb, but then strip the final executable). > But I am +1 on your proposed 'release' profile. Good! Waiting for one more +1 from another maintainer? > > == Second == > > Make wscript pick up environmental variables like CXXFLAGS_EXTRA to append them > > to automatically assembled CXXFLAGS (this may be useful for some compilation > > related experiments). > > Meh.. is this really so much useful? What is wrong about using CXXFLAGS env > var. to completely override the default flags? Well, I'm not sure, that this will be very useful for end-users, because it's rather special use case. But it can ease some plays with compiler flags, temporary defines or so. CXXFLAGS are carefully assembled throughout the whole configure() in wscript, so it's very unwisely to drop them. Blindly overriding LINKFLAGS may be disastrous. > > == Third == > > Add gcc "-pipe" option not to create temporary files (this will slightly speed > > up compilation) (must be supported even under cygwin) > > gcc "-pipe", does it really much difference? If it's always so good an option, > why doesn't gcc use it by default? Gcc doesn't enable many good options by default.:) I don't think, the difference is really measurable because of filesystem buffers and caches. There may be more noticeable improvement in case of many small C files, not several large C++ ones. But why should we produce additional overhead? > > == Fourth == > > Add gcc "-fomit-frame-pointer" option. > > This will slightly speed up execution (I've got about 1-3% speed up) and reduce > > code size, but make debugging impossible on several architectures. > > So I think it is acceptable under "release" profile (from First proposal). > > +0 (I abstain) Any unbiassed reasons? Debugging under "release" profile will be already hard to impossible. > > == Fifth == > > Add gcc "-march=native" option. > > Though it doesn't have any significant performance gains (I think due to > > intensive memory operations and bad code/data locality), it may be valuable for > > future models with intensive calculations. > > -march=native appears to be a good idea considering that ns-3 is not ever > installed or packaged for distributions. Good! Again, waiting for another +1?
(In reply to comment #7) > > gcc "-pipe", does it really much difference? If it's always so good an option, > > why doesn't gcc use it by default? > Gcc doesn't enable many good options by default.:) > I don't think, the difference is really measurable because of filesystem > buffers and caches. > There may be more noticeable improvement in case of many small C files, not > several large C++ ones. > But why should we produce additional overhead? I've made a special synthetic benchmark. In short, the reduction of system CPU time (reported by time(1)) is about 20% (reduction of NS-3 compilation time is by less than 1%). In detail, the benchmark is the following: 1) large simple preprocessed C file (actually an XPM image about 2.6M) 2) 1000 iterations with /bin/false to measure shell forking and looping overhead 3) "gcc -c file.i" to ensure the file is in cache 4) 1000 iterations with gcc -c file.i 5) 1000 iterations with gcc -c file.i -pipe Results (one run -- others are similar): 2) real 0m0.519s user 0m0.184s sys 0m0.324s 4) real 2m48.458s user 2m6.020s sys 0m33.138s 5) real 2m30.898s user 2m4.784s sys 0m26.182s So, I think, that overall NS-3 compilation time will be reduced by less than 1%. (rough estimate confirms this)
Here are some interesting patches, but NS-3 is in feature freeze, so they are better used after the NS-3.6 release, to avoid potentially breaking the release.
(In reply to comment #9) > Here are some interesting patches, but NS-3 is in feature freeze, so they are > better used after the NS-3.6 release, to avoid potentially breaking the > release. No problem. I'm doing some more benchmarks, so I can benefit from the time before open phase.:)
== Sixth == (depends on Fifth) Instruct gcc to use SSE where possible: add gcc options like "-msse{,2,3} -mfpmath=sse". My measures show that this won't give any speed improvements, but may change precision for long simulations due to rounding problems. The gcc manual says (about -mfpmath=sse): "The resulting code should be considerably faster in the majority of cases and avoid the numerical instability problems of 387 code, but may break some existing code that expects temporaries to be 80bit." For example, running prolonged wifi-wired-bridging example compiled with and without sse, gives, that pcap traces are equal, but mobility traces differs in some places. The difference isn't significant (about 2ns), but may affect strongly some special simulations.
The tree is now open for new enhancements. If you have updated versions of the patches, time to upload them...
(In reply to comment #12) > The tree is now open for new enhancements. If you have updated versions of the > patches, time to upload them... Some my planned enhancements didn't showed any performance gains and only add more complicity to wscript, so I don't have any brand new patches.
Comment on attachment 586 [details] Add "release" profile (see == First ==) Feel free to commit this patch.
Comment on attachment 587 [details] Add option "--enable-strip" (see == First ==) The 'release' profile replaces this patch.
Comment on attachment 588 [details] Respect CXXFLAGS_EXTRA (see == Second ==) Please add support for a CCFLAGS_EXTRA, besides CXXFLAGS_EXTRA. Even if ns-3-dev does not use pure C code, I know at least Mathieu is working on pure C code in a branch. And for consistency. After this change, feel free to commit.
Comment on attachment 589 [details] gcc -pipe (see == Third ==) I am still unconvinced about this patch. Why bother if the difference is so small? I say let's drop it.
-fomit-frame-pointer and -march=native, ok, I guess, but only for the 'release' profile.
(In reply to comment #14) > (From update of attachment 586 [details]) > Feel free to commit this patch. changeset 15524c57a627
(In reply to comment #16) > (From update of attachment 588 [details]) > Please add support for a CCFLAGS_EXTRA, besides CXXFLAGS_EXTRA. Even if > ns-3-dev does not use pure C code, I know at least Mathieu is working on pure C > code in a branch. And for consistency. After this change, feel free to > commit. changeset 6db6a279dfff
(In reply to comment #18) > -fomit-frame-pointer and -march=native, ok, I guess, but only for the 'release' > profile. changeset 8878efe25b6c
(In reply to comment #17) > (From update of attachment 589 [details]) > I am still unconvinced about this patch. Why bother if the difference is so > small? I say let's drop it. Well, seems you're right here, thus no one else finds this helpful. Closing bug as FIXED?