Announcement

Collapse
No announcement yet.

Ubuntu 25.04 "Plucky Puffin" Development Opens - Defaulting To -O3 Optimizations

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

  • #71
    Stop feeding it, please.

    Comment


    • #72
      Originally posted by patrick1946 View Post

      Wow, do you really think the compiler has no bugs? O3 is producing more machine code, which has the disadvantage of filling the caches. So, in the end, O3 can be slower than Os. Modern hardware does not profit so much from unrolling because the branch prediction has improved.
      You're likely correct. If I'm not mistaken, when using O2 versus O3, there maybe a longer load time, but overall the application will perform quicker.

      Rarely, if ever, have a witnessed an application reacting slower with O3, if anything difference, reacting the same if not, reacting by far quicker.

      Comment


      • #73
        Originally posted by Mark Rose View Post

        Long ago I believe -O3 enabled --no-strict-aliasing which caused bugs when used to compile code that had aliased variables. The code was not wrong.
        Most times, I've witnessed compilation statements emitting warnings.

        Code compiling fine does not necessarily mean the code was written correctly.

        Comment


        • #74
          Originally posted by rogerx View Post

          You're likely correct. If I'm not mistaken, when using O2 versus O3, there maybe a longer load time, but overall the application will perform quicker.

          Rarely, if ever, have a witnessed an application reacting slower with O3, if anything difference, reacting the same if not, reacting by far quicker.
          Instruction size is not about loading but execution. If it fills your caches with to much instructions you get more cache misses. And that is slowing down the execution.

          O3 is aggressively unrolling but with modern branch predictors that can be counter productive.

          You can see that in benchmarks, O3 has no big advantage and can be even slower. It all depends on the CPU and the program.

          Comment


          • #75
            Originally posted by patrick1946 View Post

            Instruction size is not about loading but execution. If it fills your caches with to much instructions you get more cache misses. And that is slowing down the execution.

            O3 is aggressively unrolling but with modern branch predictors that can be counter productive.

            You can see that in benchmarks, O3 has no big advantage and can be even slower. It all depends on the CPU and the program.
            More often then not, I see a significant speed increase with my Intel CPUs on my popular architectures.

            Maybe this so-called slowdown while executing branches is more typically seen with non-Intel CPUs, or other CPUs, or certain architectures. Almost all slow-downs I do see, are the initial load times of the executable file(s) being slightly larger, and typically not while the binary is executing it's functions.

            On the flip, I more so see bug or segfaults, again particularly due to likely poorly written or poorly maintained code.

            Seems I'm only getting part of the story with all of these stated slow-downs. Shrugs...

            Another possibility is the design and build quality of the computer platforms. Typically I build and invest in platforms built like a tank, with only having to upgrade every decade or more, except for my laptops. Still, my laptop(s) typically perform very well with O3 optimizations.

            Another idea, maybe people do not want to see de facto Linux distributions running as quickly as Apple and Windows, as I believe those operating system platforms are compiled with optimizations. Again, shrugs...

            I still strongly believe some Linux distributions should invest in O3 optimizations. I ran Gentoo for decades with O3 optimizations with few problems.

            Comment


            • #76
              Originally posted by rogerx View Post

              More often then not, I see a significant speed increase with my Intel CPUs on my popular architectures.

              Maybe this so-called slowdown while executing branches is more typically seen with non-Intel CPUs, or other CPUs, or certain architectures. Almost all slow-downs I do see, are the initial load times of the executable file(s) being slightly larger, and typically not while the binary is executing it's functions.

              On the flip, I more so see bug or segfaults, again particularly due to likely poorly written or poorly maintained code.

              Seems I'm only getting part of the story with all of these stated slow-downs. Shrugs...

              Another possibility is the design and build quality of the computer platforms. Typically I build and invest in platforms built like a tank, with only having to upgrade every decade or more, except for my laptops. Still, my laptop(s) typically perform very well with O3 optimizations.

              Another idea, maybe people do not want to see de facto Linux distributions running as quickly as Apple and Windows, as I believe those operating system platforms are compiled with optimizations. Again, shrugs...

              I still strongly believe some Linux distributions should invest in O3 optimizations. I ran Gentoo for decades with O3 optimizations with few problems.
              Seems your hardware is quite old. O3 is unrolling aggressively which has an advantage with not so good branch predictor. With modern branch predictors it can be the other way around.

              Comment

              Working...
              X