Announcement

Collapse
No announcement yet.

GCC 5.3 Optimization Level Tests From -O0 To -Ofast

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • GCC 5.3 Optimization Level Tests From -O0 To -Ofast

    Phoronix: GCC 5.3 Optimization Level Tests From -O0 To -Ofast

    Here are some fresh tests of Fedora 23 with the GCC 5.3.1 compiler when running a series of benchmarks after the binaries were compiled each time with an assortment of optimization levels...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    It would be interesting to see how -march=native compares at differed -O levels

    Comment


    • #3
      Originally posted by FireBurn View Post
      It would be interesting to see how -march=native compares at differed -O levels
      I was thinking the same. -O3 and -O2 at least. Would also have liked to see how -Os slotted in among the results.

      Still a worthwhile comparison though. Nice to keep track of how the -O settings compare.
      Last edited by Dick Palmer; 15 December 2015, 10:23 PM. Reason: typo

      Comment


      • #4
        -Os should be quite similar to -O2 in terms of speed but load much, much quicker. It may be a little slower at things like renderers etc. that are very CPU intensive but -Os can be a good choice for small binaries that are going to be invoked quickly and not do much actual work, or which are rarely asked to do long-term (more than 1 second, say) of processing. For example, something like BASH might be better compiled with -Os to load fast off disk, do very quick and menial tasks or a command line, and then exit. While of course built-in processing tools may require more optimisation for things like sorting, I'd say it's kind of unusual to use one of those tools on a task that would take multiple seconds (other than waiting for disk I/O), much less minutes or hours.

        Comment


        • #5
          Originally posted by phoronix View Post
          Phoronix: GCC 5.3 Optimization Level Tests From -O0 To -Ofast

          Here are some fresh tests of Fedora 23 with the GCC 5.3.1 compiler when running a series of benchmarks after the binaries were compiled each time with an assortment of optimization levels...

          http://www.phoronix.com/scan.php?pag...-New-Opt-Tests
          Note: gcc -Og is a great option for developers.

          Comment


          • #6
            Originally posted by phoronix View Post
            Phoronix: GCC 5.3 Optimization Level Tests From -O0 To -Ofast

            Here are some fresh tests of Fedora 23 with the GCC 5.3.1 compiler when running a series of benchmarks after the binaries were compiled each time with an assortment of optimization levels...

            http://www.phoronix.com/scan.php?pag...-New-Opt-Tests
            The article says "The results come largely in as expected". In my opinion, the difference between -O2 and -O3 is unexpected and it is restricted just to the two benchmarks used in the article.

            Comment


            • #7
              OMG, the first Gentooish benchmark, is it?
              gcc 5.3 is still masked, though and 4.9.3 is declared stable on amd64 Gentoo.

              I personally always go with mtune/march=native, give flags like -mmmx and so on if somthing is unsure. I use -O2 cause it is known to be safe. -O3 gives faster code but might cause problems occasionally. Also I am missing -Os in this test, that one is useful for Geodes, VIA CPUs and other units of the smaller kind. -Os works for most things; though it was said in the past that wine, libreoffice (at that time still OOo) and maybe some assembler heavy things (zsnes) might not go well with it. (So I excluded these packages from any custom cflags).
              So I'd say unless you want to debug generally or create a universal boot media one should use march=native all the way once you decide to compile things.
              Stop TCPA, stupid software patents and corrupt politicians!

              Comment


              • #8
                So far I've only used gcc 4.x and with it, I observed a performance difference between -O2 and -O3 that is smaller than the published results here.

                Guest Thank you, I was not aware of this option -Og even if I know gcc options quite well. I use to set -g in addition to -O2, it is convenient to debug without a visible loss of performance. Maybe these two approaches are similar and give the same at the end.

                phoronix It also could be nice to see such results on other architectures (I think about ARM and PowerPC), and as it was said, to extend the test with more test cases.

                Comment


                • #9
                  Originally posted by Shaman666 View Post
                  -Os should be quite similar to -O2 in terms of speed but load much, much quicker. It may be a little slower at things like renderers etc. that are very CPU intensive but -Os can be a good choice for small binaries that are going to be invoked quickly and not do much actual work, or which are rarely asked to do long-term (more than 1 second, say) of processing. For example, something like BASH might be better compiled with -Os to load fast off disk, do very quick and menial tasks or a command line, and then exit. While of course built-in processing tools may require more optimisation for things like sorting, I'd say it's kind of unusual to use one of those tools on a task that would take multiple seconds (other than waiting for disk I/O), much less minutes or hours.
                  This is the traditional viewpoint but is it really true in the modern era? My SSD is 2-3 years old now but still hits over 400MiB/s with practically zero latency, is it still the bottleneck? What about new disks like the Samsung 950 that run over 2000MiB/s? Storage technology has been moving a lot faster than processors, especially in terms of latency and random reads.

                  Comment


                  • #10
                    The optimization for size ( -Os ) is an important option, since it is often the optimization level which produces the best SIMD code. Furthermore, -Os produces more cache friendly code. From a scientific computing (floating-point centered) point of view, -Os is interesting to see.

                    Comment

                    Working...
                    X