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

31–40 of 121 posts

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#31

Post by nerpderp82 »

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…

Since it hasn't been mentioned in this entire thread, frame pointers are required to get good high resolution flame graphs.

https://www.brendangregg.com/flamegraphs.html

With systems like Phlare/Pyroscope SRE can monitor application performance in a very granular way in realtime.

https://grafana.com/blog/2023/03/15/pyroscope-grafana-phlare...

https://github.com/grafana/pyroscope

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#32

Post by brancz »

pavon wrote: post #29
daoistmonk wrote: post #5

hasn't this already been in fedora for almost a year?

Yeah. To be fair there is a stronger argument for it being enabled in fedora than an LTS release (RHEL or Ubuntu) since it has more cutting edge software that needs more frequent debugging, is less likely to be used in production where the (minor, but uneven) performance hits may matter, and has so many upstream developers using it as their daily driver.

I would argue that LTS releases are going to be deployed millions of times and stay around effectively forever with lots of very critical software being deployed on it. Having all processes/binaries be debuggable cheaply and easily in stressful situations is a major improvement that's now here to stay.

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#34

Post by cesarb »

duskwuff wrote: post #6
brancz wrote: post #2

Frame pointers are such a destructive micro-optimization to omit by default, I am beyond excited about this collaboration with the folks at Canonical to make Ubuntu debuggable by default!

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.

To emphasize this point: on 64-bit x86 with frame pointers, you have twice as many registers as on 32-bit x86 without frame pointers, and these registers are twice as wide. A 64-bit value (more common than you'd expect even when pointers are 32 bits) takes two registers on 32-bit x86, but only a single register on 64-bit x86.

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#35

Post by vaylian »

stephendause wrote: post #13

For anyone else who didn't know what a frame pointer was: https://softwareengineering.stackexchange.com/questions/1943...

For x86 that value is typically stored in the stack base pointer register (bp): https://en.wikibooks.org/wiki/X86_Assembly/X86_Architecture

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#36

Post by o11c »

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 profile, and if they do, they don't do it correctly.

Omitting frame pointers has significant performance wins on platforms with about 6 registers, like 32-bit intel x86. It's much less of a win on platforms with about 14 registers, like 64-bit x86 or 32-bit ARM, let alone platforms with about 30 registers, like 64-bit ARM.

Since modern architectures are strongly trending toward designs that support more registers, a frame pointer isn't unreasonable to choose. But that's still no excuse for all the shitty software that refuses to work correctly without them, rather than merely more slowly.

(Note that theoretically it is possible to design an ISA/ABI combo that supports easy and fast unwinding even without frame pointers, but there's always going to be some overhead and to my knowledge this choice hasn't been done.)

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#37

Post by o11c »

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).

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#38

Post by mFixman »

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…

Could programs compiled in architectures with 16 general purpose registers fail in one with 15?

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#39

Post by bodyfour »

duskwuff wrote: post #6
brancz wrote: post #2

Frame pointers are such a destructive micro-optimization to omit by default, I am beyond excited about this collaboration with the folks at Canonical to make Ubuntu debuggable by default!

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 claim that re-enabling frame pointers was the wrong choice -- the people involved in the debate know the tradeoffs and I have to start with the assumption that I would have made the same decision if I were in their position. It does make me slightly sad, though. The idea behind removing frame pointers isn't that backtraces aren't important, it's that computing the frame pointer after-the-fact is possible -- i.e. for normal functions without alloca() or dynamically-sized stack arrays map %rip -> frame size.

The problem seems to be that despite years of experience with "no-frame-pointer" being the default I guess the profiling tools never got as reliable or good as the with-frame-pointer variants. My personal hope was that the problem would fade over time as tools improved, but it seems that's unlikely to ever happen. After all, once no-frame-pointer stops being the default there won't be any pressure for tools to improve. The towel has been thrown in.

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#40

Post by brancz »

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…

Founder of Polar Signals here, the profiling product that's mentioned in the blog post. We've already made it possible to unwind without frame pointers relatively cheaply (That said, no matter how we spin it, frame pointer unwinding is always going to be cheaper, and while profiling is getting better, I think I'm almost more excited about the other aspects of debuggability this is gaining: out-of-the-box working bpftrace, bcc-tool and anything else that needs to deal with unwinding with just about anything that's running on the box. I think we'll see a huge gain in capabilities over the next few years with frame pointers more prevalent in fedora and ubuntu and I'm sure more will now follow.

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

Post reply on HN