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

91–100 of 121 posts

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#91

Post by mathiasgredal »

jcranmer wrote: post #57
mathiasgredal wrote: post #42

Earlier quoted context omitted.

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?

That's not really how registers or speculative execution works. Intuitively, you can think of assembly as trying to describe a graph of instruction dependencies. Having 16 registers in the ISA allows you to have 16 live outputs at any given "time". Speculative execution allows instructions to execute out-of-order, and to enable this, it has ~140 registers that allow it to have 140 live outputs at once, so that it can…

I get that there is a tradeoff with code density, although if you could have an encoding scheme or extended register mode to alleviate this. I was just thinking that if you have e.g a loop where you run out of registers, since you only have 16, then the compiler will swap the values to memory and reuse that register which creates an instruction dependency that doesnt really have to exist.

If the compiler could use the hidden registers, then the cpu would know that it could run this instruction ahead of time.

It is probably not worth it, since it adds a lot of complexity to an already complex system, which is why it isn’t done.

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#92

Post by peterfirefly »

mathiasgredal wrote: post #91
jcranmer wrote: post #57

Earlier quoted context omitted.

That's not really how registers or speculative execution works. Intuitively, you can think of assembly as trying to describe a graph of instruction dependencies. Having 16 registers in the ISA allows you to have 16 live outputs at any given "time". Speculative execution allows instructions to execute out-of-order, and to enable this, it has ~140 registers that allow it to have 140 live outputs at once, so that it can…

I get that there is a tradeoff with code density, although if you could have an encoding scheme or extended register mode to alleviate this. I was just thinking that if you have e.g a loop where you run out of registers, since you only have 16, then the compiler will swap the values to memory and reuse that register which creates an instruction dependency that doesnt really have to exist. If the compiler could use th…

All AMD64 CPUs support at least SSE2 which means they have 16 (not 15 or 14!) XMM registers they can spill to. This is just as fast as a move between two GPRs.

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#93

Post by brendangregg »

londons_explore wrote: post #66

So the whole world should take a 1-2% performance penalty on everything so some users can maybe run a profiler? Wouldn't it make more sense to just have an 'apt reinstall all --with-frame-pointers' command that power users could run before they wanted to profile something?

I don't know where 1-2% comes from, but for many scale production workloads I studied it was so close to 0% that it was tough to measure beyond noise on the cloud. That's not to say that 1-2% is wrong, but that it's likely someone's workload and other people see less.

Helping people find ~30-3000% perf wins, helping debugging and automated bug reports, is huge. For some sites it may be like 300 steps forward, one step back. But it's also not the end of the road here. Might we go back to frame pointer ommision one day by default if some other emerging stack walkers work well in the future for all use cases? It's a lot of ifs and many years away, and assumes a lot of engineering work continues to be invested for recoving a gain that's usually less than 1%, but anythings possible.

There's a couple of problems with an apt reinstall. One is that people often don't work on performance until the system is melting down -- many times I've been handed an issue where apt is dreadfully slow due to the system's performance issue and just installing a single package can take several minutes -- imagine reinstalling everything, it could turn the outage into over an hour! The other is I'd worry that reinstalling everything introduces so many changes (updating library versions) that the problem could change and you'd have no idea which package update changed it. If there was such an apt reinstall command, I know of large sites (with experience with frame pointer overheads) that would run it and then build their BaseAMI so that it was the default. Which is what Ubuntu is doing anyway.

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#94

Post by westurner »

westurner wrote: post #4

Call stack > Structure > Stack and Frame pointers : https://en.wikipedia.org/wiki/Call_stack#Stack_and_frame_poi... What do the Coding Guidelines listed in e.g. awesome-safety-critical say about Frame pointers? https://awesome-safety-critical.readthedocs.io/en/latest/#co... (Edit) /? "cert" "frame pointer" https://www.google.com/search?q=%22cert%22+%22frame+pointer%... : - Stack buffer overflow > Exploiting stack buf…

When frame pointers are omitted, there are fewer places in memory that can be overwritten to hijack control flow of a program.

Someone could easily prepare an demo of a frame pointer buffer overflow exploit to explain?

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#95

Post by o11c »

brancz wrote: post #43
o11c wrote: post #37

Earlier quoted context omitted.

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

"Software that runs at scale" is a very different story than "Software that is shipped with a distro", unfortunately.

Very few distro packages can even define what a normal workload looks like.

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#96

Post by nightowl_games »

alexey-salmin wrote: post #88
londons_explore wrote: post #66

So the whole world should take a 1-2% performance penalty on everything so some users can maybe run a profiler? Wouldn't it make more sense to just have an 'apt reinstall all --with-frame-pointers' command that power users could run before they wanted to profile something?

I've seen how instantly-available profiles affect the engineering culture on practice and it's transformative. The difference between "yeah strange, I'll deploy an fp build some time later and check... maybe" and "see this thing right here on the flamegraph" is huge and often repays 5-15x of the initial 1% slowdown.

This x1000

This "1%" loss will never manifest. It will be pure gain.

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#97

Post by dralley »

o11c wrote: post #95
brancz wrote: post #43

Earlier quoted context omitted.

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

"Software that runs at scale" is a very different story than "Software that is shipped with a distro", unfortunately. Very few distro packages can even define what a normal workload looks like.

That's precisely why it's nice for users to be able to collect these profiles themselves.

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#98

Post by not_the_fda »

PeterisP wrote: post #79
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…

Does this provide there any benefit at all to the majority of machines which aren't intended to be used for development of binaries (i.e. user workstations, developers working with interpreted languages, and servers), what would be the use cases where frame pointers would help on those machines? Like, even for developers, I assume a random web development shop using Ubuntu and hosting stuff on Ubuntu would likely not…

No benefit, but no downside either, its effectively irrelevant, an implementation detail.

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#99

Post by coldtea »

londons_explore wrote: post #66

So the whole world should take a 1-2% performance penalty on everything so some users can maybe run a profiler? Wouldn't it make more sense to just have an 'apt reinstall all --with-frame-pointers' command that power users could run before they wanted to profile something?

>So the whole world should take a 1-2% performance penalty on everything so some users can maybe run a profiler?

If so, I'm all for it. The win from easy access to profiling can dwarf this 1-2%

Re: Ubuntu 24.04 LTS will enable frame pointers by default

#100

Post by comex »

AndyKelley wrote: post #86

Why not let the upstream application developer decide, rather than choosing for them? This is one of the downsides of using C/C++ rather than a modern programming language like Rust or Zig. In the former case, the system maintainers reach across the table and change the settings, despite what the actual application developer has chosen. In the latter, the upstream developers' choices are respected more, mainly becaus…

Because the upstream developer is not the only one who needs to profile the program.

For one thing, you might be the upstream developer of a library the program links against, and your stack frames might be hidden under frames from the program that didn’t save the frame pointer. Or if it’s a library that isn’t saving the frame pointer, vice versa.

But the more interesting use case is if you’re not the upstream developer of anything, but a skilled user who wants to get a view of your entire system and diagnose problems yourself. Personally I do that all the time, both in my spare time and at work. With respect to performance in particular I have more experience with the macOS tooling than the Linux tooling, but it’s analogous – with tools like Instruments and dtrace I can get a profile of any process I want or of the entire system, and I find that incredibly valuable. And that’s made possible in part by the stock macOS toolchain enabling frame pointers by default.

The NixOS case you linked sounds rather annoying, but turning on optimizations and -Werror and PIC by default is very different from just enabling frame pointers by default.

Post reply on HN