Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ubuntu 24.04 LTS will enable frame pointers by default

ubuntu.com

Post reply on HN
Print view View original

41–50 of 121 posts

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#41

Post by brancz »

bodyfour wrote: post #39
duskwuff wrote: post #6

Earlier quoted context omitted.

This option was almost certainly a holdover from the bad old 32-bit x86 days, when disabling frame pointers gave you a seventh valuable general-purpose register. It's no longer beneficial on x86_64 -- even with rbp locked down, you still have fourteen registers there.

That much is true -- the difference between 6 and 7 registers is much larger than the benefit of going from 14 to 15. However, even under zero register pressure having a frame pointer is still an extra register that needs to be touched on every function invocation, extra instructions taking space in the I-cache, etc. It's a small thing, but it's still a cost that has to be paid by all compiled code. I'm not going to…

Profiling tools have already solved the ability to reliably unwind in the absence of frame pointers[1], but there are plenty of tools that this kind of investment is simply too much that it won't ever happen, like bpftrace or bcc-tools.

[1] https://www.polarsignals.com/blog/posts/2022/11/29/dwarf-bas...

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#42

Post by mathiasgredal »

jcranmer wrote: post #26
herodoturtle wrote: post #11

For the layman, what does this mean?

There are two key effects of this decision. The first effect is that it makes one additional general-purpose integer register unavailable for use for code. x86-64 has 16 general-purpose registers, but one of these is the stack pointer and basically can't be used for any other purpose; this would add a second reserved register for the frame pointer. This effect may cause slowdowns if the 15th register was critical for…

I thought modern speculative cpu’s had way more registers than you can normally access. Why does it reserve these registers for speculative execution instead of exposing them to the program if it needs them?

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#43

Post by brancz »

o11c wrote: post #37
amne wrote: post #14

Even in context it is hard to understand this: "The performance wins that these can provide far outweigh the comparatively tiny loss in performance." My guess is that on average the potential performance discovered with the techniques this enables is higher than the guaranteed negligible performance loss.

That is highly optimistic though. Profiling is hard even when you know what you're doing, and doing it wrong can easily lead to pessimization (thinking particularly about if your profiling workload exercises a different set of branches).

Hyperscalers have long been doing infrastructure-wide profiling (or "Google-Wide Profiling" as the first whitepaper on the topic calls it [1]). This tech allows Google to reduce infra-resource usage by multiple percentage points per quarter.

[1] https://research.google/pubs/google-wide-profiling-a-continu...

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#45

Post by andreyv »

mathiasgredal wrote: post #42
jcranmer wrote: post #26

Earlier quoted context omitted.

There are two key effects of this decision. The first effect is that it makes one additional general-purpose integer register unavailable for use for code. x86-64 has 16 general-purpose registers, but one of these is the stack pointer and basically can't be used for any other purpose; this would add a second reserved register for the frame pointer. This effect may cause slowdowns if the 15th register was critical for…

I thought modern speculative cpu’s had way more registers than you can normally access. Why does it reserve these registers for speculative execution instead of exposing them to the program if it needs them?

The number of registers available to the program is fixed in the instruction set. The program cannot address more registers without recompiling it to an extended instruction set.

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#48

Post by mdpye »

mathiasgredal wrote: post #42
jcranmer wrote: post #26

Earlier quoted context omitted.

There are two key effects of this decision. The first effect is that it makes one additional general-purpose integer register unavailable for use for code. x86-64 has 16 general-purpose registers, but one of these is the stack pointer and basically can't be used for any other purpose; this would add a second reserved register for the frame pointer. This effect may cause slowdowns if the 15th register was critical for…

I thought modern speculative cpu’s had way more registers than you can normally access. Why does it reserve these registers for speculative execution instead of exposing them to the program if it needs them?

Because then it would need more registers for the other purpose?

But actually the decision about which general purpose registers to use for what is made at compile time (hence we're discussion a compiler flag here, the frame pointer is not a hardware dictated feature), so the question is actually kind of moot. If the compiler is out of registers to allocate and instead uses the stack, the CPU isn't reasonably going to be able to undo that.

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#49

Post by [deleted] »

ghotli wrote: post #30

I somewhat painstakingly figured this out the hard way pulling core dumps off of embedded linux devices that gdb had a hard time working with. At the time I was like whew why is omitting frame pointers the default at all in so many places when it didn't seem to make a measurable difference in the performance of the software. I guess it's just vestigial these days and yes please use a compiler flag like this when it m…

[deleted]

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#50

Post by stefan_ »

o11c wrote: post #36
ghotli wrote: post #30

I somewhat painstakingly figured this out the hard way pulling core dumps off of embedded linux devices that gdb had a hard time working with. At the time I was like whew why is omitting frame pointers the default at all in so many places when it didn't seem to make a measurable difference in the performance of the software. I guess it's just vestigial these days and yes please use a compiler flag like this when it m…

Something has to be seriously wrong with the way it was compiled for gdb to have trouble. Debugging (or in-process exception dumps), which only does a reasonable number of backtraces, should always be able to use separate unwind data sections. Including frame pointers should only have a performance effect for sample-based profiling, which does a very large number of backtraces. And the general fact is - people don't…

Embedded devices, certainly in the days of 16 MiB NOR flash, do not contain unwind or debug information. Even today OpenWrt and similar will routinely strip all binaries installed to the final firmware image.

There are some structural issues in the Linux world, too; the default of debug data contained within the binary is often undesirable, symbol servers (they finally learned about those in Ubuntu 22) require extra setup & tooling support that isn't often invested in, widely used libraries like libunwind are both arcane and terrible (yes, an instruction pointer of 0 will not have associated unwind information; use your brain and realize someone called a NULL function pointer).

Post reply on HN