1. 5

  2. 5

    This feels like the beginning of a new funroll-loops.org

    1. 3

      I agree that per the documentation -pipe should improve compilation speed, but IME it makes little difference. Perhaps this was more important on older hardware/filesystems, or perhaps it makes more of a difference for C than it does for C++.

      1. 1

        I agree 100%. Moreover, It really only says this in the Gentoo wiki. The GCC documentation don’t make any promises:


        Use pipes rather than temporary files for communication between the various stages of compilation. This fails to work on some systems where the assembler is unable to read from a pipe; but the GNU assembler has no trouble.

        Seems like if your filesystem is fast at handling small temporary files (something about sync behaviour, probably) then there’s not going to be much difference.

        1. 2

          Good point – I hadn’t thought about sync. Probably relatime helps, too (I don’t think it existed when -pipe was invented).

      2. 2

        I’d hoped for a bit more discussion on -O2 vs -O3. Does anyone have any anecdata as to what to prefer?

        1. 2

          1st point is only valid when you compile on i386/amd64. You should do some check on what architecture you compile.

            1. 1
              1. This is a new development, present in GCC9. Most people will use older compilers for some time.
              2. This only adds aarch64, e.g. ppc64 is still affected.
              1. 1

                I don’t have arm environment at hand. https://www.phoronix.com/scan.php?page=news_item&px=GCC-8-march-native-ARM says gcc-8 should support -march=native option, is it wrong? Thanks!

                1. 1

                  I can assure you it doesn’t work on ppc64 with GCC8 :)

                  1. 1

                    I think most users use X86 and ARM nowadays. If -march is already supported on these two platforms, I think it should be OK. :-)

                    1. 1

                      With Raptor boards being widely available, there’s much development happening in ppc64 nowadays, so not having it available on ppc64 is a big minus.

                      1. 2

                        Some guy gave a whole talk about these annoying shortcuts at asiabsdcon. More people should read his paper. :)


                        1. 3

                          Nice, looks like someone actually read my paper :)

          1. 1

            (2) -O2 is recommended. But if play with cmake, “cmake -DCMAKE_BUILD_TYPE=Release ..” will use -O3 to compile code. At least from my own experience,-O3 should be OK.

            I thought this was a strange statement to make until I saw the linked wiki page context of “advice for Gentoo users’ configurations”.

            Compiler optimisation performance is like any other kind of performance: whether you get improvements depends on what your workload looks like.

            For C program authors, whether or not a compiler optimisation level “should be OK” depends entirely on your code.

            • Did you write code with Undefined Behaviour? Then adding more optimisation levels may suddenly break your code completely, which is clearly not OK.
            • Did you not write code with Undefined Behaviour? Then (apart from very rare compiler bugs) you can expect things will be OK no matter what optimisations you turn on (it may not get faster, but that’s a different question).
            • How do you know if you wrote Undefined Behaviour? As far as I’ve experienced this is a maze of traps for C programmers, but thankfully we have UBSan on most platforms.

            In the context of Gentoo users in particular, you’re trying to decide the safe settings to compile every program in your distro with, so you can be sure that you’ve clawed out that last 1% of illusive (imagined?) performance gains. I would think the prudent thing for a Gentoo user would be to choose the lowest common denominator of safety, as it’s impossible to audit every line of C & C++ code your distro is running. But YMMV.