21–30 of 121 posts
For the layman, what does this mean?
[1] https://www.polarsignals.com/blog/posts/2022/11/29/dwarf-bas...
hasn't this already been in fedora for almost a year?
I believe so, I remember a fair amount of hubbub over it. Can't say it's been useful here, any development I do is miles away from this. It hasn't hurt either so... cool, I guess Call me pessimistic, but I'm not convinced this being the default will lead to more profiling. There's plenty that could be done without this, that isn't, so I'm not buying it.
Profiling is one part, but the debuggability this enables is going to be huge in the long term I predict.
Remove snap (or choose a Ubuntu distro variant like Pop OS without snap)
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.
Pro tip for performance optimisation in Ubuntu (you also gain more RAM): Remove snap (or choose a Ubuntu distro variant like Pop OS without snap)
For the layman, what does this mean?
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 performance.
The second effect is on the ability to identify (and potentially unwind) the stack trace. With frame pointers, the pseudocode for computing a stack trace is essentially:
do
load return address, previous frame pointer from current frame pointer
print return address
move previous frame pointer into current frame pointer
until current frame pointer is invalid
while current address has corresponding entry in unwind table:
parse unwind table entry to find a program to run
run this program on the current frame to generate return address
print return address
move return address to current address
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.
The Amd64 architecture fixed the underlying problem, so this is pretty much just a holdover. I'm surprised they even enabled it by default.
Pro tip for performance optimisation in Ubuntu (you also gain more RAM): Remove snap (or choose a Ubuntu distro variant like Pop OS without snap)
Is that even practical nowadays? My understanding is that snap is deeply integrated. Don't some apt packages point to their snap variants?
I believe Firefox now points to its snap variant, which I discovered when it broke a bunch of my browser extensions. Switching to the official Mozilla PPA was easily enough, but left a bad taste; if Canonical continues down the route of silently nudging users onto snap, I’ll probably switch to Debian.
(I have no particular opinions about snap itself, other than that it seems poorly documented and doesn’t adhere to the “do what I say” philosophy when it’s secretly injected into apt.)
hasn't this already been in fedora for almost a year?