Hacker News Reader

Comment by nneonneo | Hacker News Reader

The article points out that the kernel uses ORC instead of DWARF for unwinding. I wonder if that could ever become an option in userspace? I imagine that if all you’re interested in is stack traces, instead of debugging (which DWARF is designed for), ORC would be a very nice performance win. And it’s not as if they’re mutually exclusive, either: there’s no reason why a binary or debuginfo couldn’t just ship both.

In any case, the runtime performance hit of frame pointers is quite high, and since we do have things like DWARF (and maybe ORC someday?), I’d still argue that frame pointers aren’t necessary. It’s nice to have that extra register free!

View on HN

Native ORC generation from GCC or LLVM or userspace tooling like objtool would be nifty.

FWIW, ORC was specifically designed to be efficient, but it was not designed to be future-proof against complex toolchain changes. Since all the ORC tooling is in the kernel, it can evolve together if needed.

(I was a bit involved in the design — I helped optimize the format to reduce cache misses on lookup.)

For prodfiler.com we convert .eh_frame (DWARF) unwinding format to something that is more similar to ORC and optimized for lookup in eBPF data structures.

> In any case, the runtime performance hit of frame pointers is quite high

That's not true at all. It's in some very rare cases. Firefox I think at this point ships with framepointers enabled and so does every M1/M2 mac app and all iOS applications as it's mandatory for the calling convention on Apple.

On AArch64 I think it's cheaper because losing one register doesn't hurt as much, since you've got twice as many.

nitpick: it's the number of physical registers that matter more here, not ISA registers

Why wouldn't the lower ISA register count lead to more spills, regardless of the physical count? Is store forwarding really that effective?

It isn't.

The ORC documentation [1] cites a 5-10% perf hit [2] on x86. Now, granted, we're talking about an architecture that has only 8 logical registers to begin with, so losing one is going to hurt a lot more than x86-64 (16 logical registers) or AARCH64 (32 logical registers). But, 5-10% is definitely a noticeable perf hit.

Phoronix [3] did a test of "-fno-omit-frame-pointer" during the discussion on whether to enable the flag for Fedora, this time on x86-64. They found an average 14% performance hit on a wide variety of benchmarks.

[1] https://www.kernel.org/doc/html/latest/x86/orc-unwinder.html [2] https://lore.kernel.org/all/20170602104048.jkkzssljsompjdwy@... [3] https://www.phoronix.com/review/fedora-frame-pointer/5

See also https://lists.fedoraproject.org/archives/list/devel@lists.fe... - the botan phoronix results with frame pointers were probably measuring debug builds.

Reply on news.ycombinator.com