Am 27.11.24 um 04:42 schrieb Andrii Nakryiko:
On Tue, Nov 26, 2024 at 6:43 PM Aaron Puchert <aaronpuchert@alice-dsl.net> wrote:
Am 25.11.24 um 23:59 schrieb Andrii Nakryiko:
[...] DWARF's .eh_frame-based stack unwinding tables. The latter is actually doesn't land itself well to system-wide profiling, and involved compromises in memory usage, CPU usage, and just plain reliability (no one will guarantee you that you captured all of the stack, for example). The first two arguments are problematic: remember that we're talking about frame pointers, which cost CPU for all users. On one hand you're But how much CPU does it actually cost? You can see 1-2% in *benchmarks*,
Sure, that was my understanding. But 1% across everything is not a small regression. I know you're arguing that lots of tools don't even support DWARF unwinding, but let's just focus on those that do: even if 2% of users does profiling, and the overhead is 20%, we have an average CPU usage cost of 0.4% for DWARF, which is still below 1%. (That's assuming those users are profiling all the time.) So total CPU usage across all users is going to go up if we enable FP. And it's not given at all that we get benefits of the same order. In individual programs we can certainly get much more, but across all workloads I doubt it. Most CPU-intensive applications are already subject to heavy profiling. From the Fedora Proposal:
Compiling the kernel with GCC is 2.4% slower with frame pointers That's quite a bit for a compiler. The LLVM compile-time tracker [1] shows "instructions" instead of "cycles" per default because the latter is too noisy for the regressions that we're interested in, which is basically everything >0.5%. Given that I've spend time on trying to get some 0.5% improvements, I'm not sure that I'm willing to accept a 2.4% regression. But if we enable frame pointers globally and I disable them in LLVM, I make other people mad.
there is no perceptible CPU overhead associated with that.
Not perceptible yes, because it's rather equitably distributed. But in terms of total cost it's much more significant than most perceptible regressions. I've said this in the beginning: I'm not against frame pointers, but I don't like how quickly we're willing to wave away the cost and acceptability of out-of-band alternatives. [1] <http://llvm-compile-time-tracker.com/>