Announcement

Collapse
No announcement yet.

Fedora's FESCo Rejects The Idea Of "-fno-omit-frame-pointer" As Default Compiler Flag

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

  • Fedora's FESCo Rejects The Idea Of "-fno-omit-frame-pointer" As Default Compiler Flag

    Phoronix: Fedora's FESCo Rejects The Idea Of "-fno-omit-frame-pointer" As Default Compiler Flag

    The past few months there has been a change proposal discussed around adding "-fno-omit-frame-pointer" to the default compilation flags for packages being built for Fedora Linux. Adding this option would improve the profiling/debug-ability of the packages but with possible performance implications. The Fedora Engineering and Steering Committee (FESCo) has now rejected this contentious change proposal...

    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
    Shouldn't it be possible to identify the stack layout from the debug Info and the instruction pointer? Which should be enough to infer the frame address.

    The only issue I can see with this approach is alloca or other variable sized allocations on the stack. But those seem like a bad idea in general to me: either your variable sizes data is small enough to always fit on the stack, in which case why not do a fixed size buffer? Or you risk blowing the stack size and should have allocated on the heap to begin with.

    Comment


    • #3
      Somthing I don't understand here. If I use -g for debugging builds, it should allready include no-omit-frame-pointer. If using -o2 than I certainly don't want debugging stuff in my release.

      Comment


      • #4
        Originally posted by Anux View Post
        Somthing I don't understand here. If I use -g for debugging builds, it should allready include no-omit-frame-pointer. If using -o2 than I certainly don't want debugging stuff in my release.
        A lot of the typical questions include these is addressed in the change proposal. They want to use this in production and not just for debugging, the FESCO ticket linked mentions that Google also does this. https://fedoraproject.org/wiki/Chang...in_production?

        Comment


        • #5
          Why can't they spin a debug build where they can enable all of these debug features by default if they want?! If there is one thing the release build doesn't need it is performance regressions.

          Comment


          • #6
            Originally posted by RahulSundaram View Post

            A lot of the typical questions include these is addressed in the change proposal. They want to use this in production and not just for debugging, the FESCO ticket linked mentions that Google also does this. https://fedoraproject.org/wiki/Chang...in_production?
            Yeah sorry, just read it myself. But why make it standard, they allready use those flags, so it's not like it's hard to do. If they don't care about a little performance loss there is also -Og.

            I don't understand why they would make that standard in any -O > 1.

            Comment


            • #7
              Originally posted by Anux View Post
              Yeah sorry, just read it myself. But why make it standard, they allready use those flags, so it's not like it's hard to do
              They have to rebuild the entire distro for their internal builds which they can certainly continue to do but they have been attempting to upstream their desired changes which is generally a good thing to do. These internal changes otherwise tend to become tech debt over time. At the data center scale, the net performance and developer efficiency gains are worth it for them. For other folks, the situation is less clear. The desktop team apparently wants it because it saves them time running their tools and several upstream projects are enabling the flags by default but other teams including the tooling team thinks it's not worth the tradeoffs.

              Comment


              • #8
                Originally posted by Vorpal View Post
                Shouldn't it be possible to identify the stack layout from the debug Info and the instruction pointer? Which should be enough to infer the frame address.

                The only issue I can see with this approach is alloca or other variable sized allocations on the stack. But those seem like a bad idea in general to me: either your variable sizes data is small enough to always fit on the stack, in which case why not do a fixed size buffer? Or you risk blowing the stack size and should have allocated on the heap to begin with.
                Yes, this approach is very much possible. In fact nearly every tool supports this. The only downside is that when using perf, the stack needs to be copied on every sample because Linux doesn't contain a DWARF parser.

                Comment


                • #9
                  Originally posted by RahulSundaram View Post

                  They have to rebuild the entire distro for their internal builds which they can certainly continue to do but they have been attempting to upstream their desired changes which is generally a good thing to do. These internal changes otherwise tend to become tech debt over time. At the data center scale, the net performance and developer efficiency gains are worth it for them. For other folks, the situation is less clear. The desktop team apparently wants it because it saves them time running their tools and several upstream projects are enabling the flags by default but other teams including the tooling team thinks it's not worth the tradeoffs.
                  Hm ok. But still not worth a standard just to make it easier for a few million dollar companies. According to Michaels benchmarks there are workloads that get their throughput halfed from just no-omit-F-P.

                  Sorry for asking another uninformed question. What has upstreaming to do with compiler flags? Shouldn't that be totally independend?

                  Comment


                  • #10
                    Originally posted by Anux View Post

                    But still not worth a standard just to make it easier for a few million dollar companies....

                    Sorry for asking another uninformed question. What has upstreaming to do with compiler flags? Shouldn't that be totally independend?
                    As I have noted, it isn't just large organizations, individual developers depending on the group want this too and any performance improvements done by either can flow to everyone. So the tradeoffs are more complex.

                    From the distribution perspective, compiler flags aren't independent because the whole change proposal is about changing the distribution default compiler flags and it is the upstream for whatever internal rebuilds that organizations like Meta are using and not the individual projects. Also the individual upstream projects are also often impacted by whatever flags major distributions use as well since they get performance feedback and bug reports from them. Changing a major distribution flags tend to affect the ecosystem pretty broadly.
                    Last edited by mether; 01 December 2022, 11:19 AM.

                    Comment

                    Working...
                    X