3 ms·
IMHO this argument is on the wrong side of the fence. The advantages to auditing and long-term quality to a distro having guaranteed-usable backtraces are just
by ajross 4y ago
IMHO this argument is on the wrong side of the fence.
The advantages to auditing and long-term quality to a distro having guaranteed-usable backtraces are just too much to pass up. Absolutely Fedora needs to disallow -fomit-frame-pointer. I just don't see a 2-3% performance argument as being responsive there. Applications with performance tuning requirements at that scale are going to be more than able to, y'know, recompile their junk. Frankly most runtimes these days prefer to deploy static binaries anyway. The default distro isn't the place to be dithering over 2%.
But what this is really measuring isn't the cost of a "frame pointer". It's the cost of a ABI-compliant function call. And there's technology available that reduces the number of these damn near zero (with no impact to backtrace generation or debuggability), which would obviate all the argumentation over -f-o-f-p.
Get LTO working, everyone: https://fedoraproject.org/wiki/LTOByDefault https://fedoraproject.org/wiki/LTOByDefault
- dezgeg 4y ago> And there's technology available that reduces the number of these damn near zero (with no impact to backtrace generation or debuggability), which would obviate all the argumentation over -f-o-f-p. Any pointers on such solution? And why couldn't it be applied right now, without LTO?
- nix0n 4y ago> no impact to backtrace generation or debuggability That wasn't my experience with MSVC's implementation of LTO. In particular, eliminating ABI-compliant function calls meant that those functions were eliminated from the callstack as shown by the debugger. Are GCC or perf better about that, somehow?