Fedora Decides After All To Allow Default Compiler Flag To Help Debugging/Profiling
The past several months saw much discussion over a proposal to add "-fno-omit-frame-pointer" as a default compiler flag to Fedora Linux that would improve profiling/debugging but with possible performance implications that can vary based on the application/workload. While just over one month ago FESCo rejected that change, they re-voted today and decided after all to allow this change to happen but to ensure that packages can easily opt-out if they find performance regressions. By Fedora 40 they will also re-visit the matter to determine if the benefits and performance costs are justified.
At today's Fedora Engineering and Steering Committee (FESCo) they re-voted on the change of adding -fno-omit-frame-pointer to the default compiler flags when building packages for Fedora Linux. The compiler option ensures that a frame pointer is always available but when currently omitting it, three instructions per function are saved and the RBP frame/base pointer register can be used as a general purpose register for other purposes. This option helps with profiling and debugging of Fedora software but with varied performance costs.
There are some performance hits and in the past SUSE engineers have characterized it as in the possible 5~10% range depending upon the particular software. Meta/Facebook engineers have been eager to push this change for Fedora while some GNOME developers would also like to see it happen for the improved debugging/profiling being enough to justify any performance costs.
For making the change easier to swallow with the second round of voting, a new knob is added to make it easier for RPM package maintainers to opt out of having this compiler flag should they find the performance be negatively impacted too much.
So today's FESCo meeting outcome was:
Thus the change can move forward for Fedora 38 due out in April. It will be interesting to see how well this works out in practice as well as curiously seeing how many packages end up opting-out of this feature and how much of that opting-out is done just after the fact from any user complaints / bug reports over lost performance. It will be interesting to benchmark in any case.
At today's Fedora Engineering and Steering Committee (FESCo) they re-voted on the change of adding -fno-omit-frame-pointer to the default compiler flags when building packages for Fedora Linux. The compiler option ensures that a frame pointer is always available but when currently omitting it, three instructions per function are saved and the RBP frame/base pointer register can be used as a general purpose register for other purposes. This option helps with profiling and debugging of Fedora software but with varied performance costs.
There are some performance hits and in the past SUSE engineers have characterized it as in the possible 5~10% range depending upon the particular software. Meta/Facebook engineers have been eager to push this change for Fedora while some GNOME developers would also like to see it happen for the improved debugging/profiling being enough to justify any performance costs.
For making the change easier to swallow with the second round of voting, a new knob is added to make it easier for RPM package maintainers to opt out of having this compiler flag should they find the performance be negatively impacted too much.
So today's FESCo meeting outcome was:
AGREED: APPROVED (+6,1,-1) This Change is implemented for Fedora Linux 38 and we evaluate whether to retain it by Fedora Linux 40. This Change must be implemented in a manner which packages are able to trivially opt-out of retaining frame pointers during compilation so that packages that take larger performance hits can easily revert.
Thus the change can move forward for Fedora 38 due out in April. It will be interesting to see how well this works out in practice as well as curiously seeing how many packages end up opting-out of this feature and how much of that opting-out is done just after the fact from any user complaints / bug reports over lost performance. It will be interesting to benchmark in any case.
55 Comments