5 ms·

Didn’t really get the point of the post as it just presents something without a conclusion. 9X% of users do not care about a <1% drop in performance. I suspect

by elteto 2y ago

Didn’t really get the point of the post as it just presents something without a conclusion. 9X% of users do not care about a <1% drop in performance. I suspect we get the same variability just by going from one kernel version to another. The impact from all the Intel mitigations that are now enabled by default is much worse. However I do care about nice profiles and stack traces without having to jump through hoops. Asking people to recompile an _entire_ distribution just to get sane defaults is wrong. Those who care about the last drop should build their custom systems as they see fit, and they probably already do.

yosefk 2y ago
it does present a conclusion. once the kernel supports .sframe it will be all-around superior to -fomit-frame-pointer, and a better default for distros to use.
- audidude 2y ago
  It does cause more memory pressure because the kernel will have to look at the user-space memory for decoding registers. So yes it will be faster than alternatives to frame-pointers, but it still wont be as fast as frame pointers.
Brian_K_White 2y ago
But does what you care about matter enough to be the default? Are you the majority? Evaluate "majority" this way: For every/any random binary in a distro, out of all the currently running instances of that binary in the world at any given moment, how many of those need to be profiled? There is no way the answer is "most of them". You have a job where you profile things, and maybe even you profile almost everything you touch. Your whole world has a high quotient of profiling in it. So you want the whole system built for profiling by default. How convenient for you. But your whole world is not the whole world. But it's not just you, there are, zomg thousands, tens of thousands, maybe even hundreds of thousands of developers and ops admins the same as you. Yes and? Is even that most installed instances of any given executable? No way. Or maybe yes. It's possible. Can you show that somehow? But I will guess no way and not even close.
- audidude 2y ago
  I regularly have users run Sysprof and upload it to issues. It's immensely powerful to be able to see what is going on systems which are having issues. I'd argue it's one of the major reasons GNOME performance has gotten so much better in the recent-past. You can't do that when step one is reinstall another distro and reproduce your problem. Additionally, the overhead for performance related things that could fall into the 1% range (hint, it's not much) rarely are using the system libraries in such a way anyway that would cause this. They can compile that app with frame-pointers disabled. And for stuff where they do use system libraries (qsort, bsearch, strlen, etc) the frame pointer is negligible to the work being performed. You're margin of error is way larger than the theoretical overhead.
  - Brian_K_White 2y ago
    1% is a ton. 1% is crazy. Visa owns the world off just a 3% tax on everything else. Brokers make billions off of just 1% or even far less. 1% of all activity is only rational if you get more than 1% of all activity back out from those times and places where it was used. 1%, when it's of everything, is an absolutely stupendous collossal number that is absolutely crazy to try to treat as trivial.
    - ploxiln 2y ago
      Better analogy: you're paying 30% to apple, and over 50% in bad payday loans, and you're worried about the 3% visa/stripe overhead ... that's kinda crazy. But that's where we are in computer performance, there's 10x, 100x, and even greater inefficiencies everywhere, 1% for better backtraces is nothing.
      - audidude 2y ago
        Absolutely. We've gotten numerous double digit performance improvements across applications, libraries, and system daemons because of frame-pointers in Fedora (and that's just from me).
- wbl 2y ago
baq 2y ago
fifty independent 1% performance drops nobody cares about compound to a ~40% reduction.
- dralley 2y ago
  No, that's not how it works. You don't stack 1% losses of the total application performance on top of each other just because your application uses 40 libraries.
josefx 2y ago
> 9X% of users do not care about a <1% drop in performance. Except Python got opted out of the frame pointer change due to benchmarks showing slowdowns of up to 10%. The discussion around that had the great idea of just adding a pragma to flat out override the build setting. So in the end that "%1" reduction claim only holds if everything even remotely affected silently ignores the flag.
- audidude 2y ago
  This is a bit of a mischaracterization of the Python side of things. They only opted out for 3.11 which did not yet have the perf-integration fixes anyway. 3.12 uses frame-pointers just fine.
  - josefx 2y ago
    Any link to the fix or documentation about it? I could find added perf support but did not see anything about improved performance related to frame pointer use.
    - audidude 2y ago
      https://pagure.io/fesco/issue/2817#comment-826636 https://pagure.io/fesco/issue/2817#comment-826636 will probably get you started into the relevant paths. Python 3.12 was going to include frame-pointers anyway for perf to boot. So they needed to fix this regardless.
j16sdiz 2y ago
> 9X% of users do not care about a <1% The same could be said about any accessibility issue or minority language translations
- jchw 2y ago
  This comparison is pretty misleading. An accessibility issue prevents someone from being able to use software effectively. Not having localized text would have a similar impact. A ~1% performance impact on the other hand is the minuscule downside of improving debugging, profiling and error reporting for an entire OS. And that's not just a minority of users, as tons of software will automatically gather stack traces for bug reports. There's basically no downside to fixing accessibility issues or adding new language translations other than the work involved in doing so. (And yes, maintaining translations over time is hard, but most projects let them lag during development, so they don't directly hold anything back.) There is a rather glaring downside to this performance optimization, whose upside is sometimes entirely within run-to-run variance and can be blown away by almost any other performance tweak. It's clear the optimization has some upsides, but an extra register and saving some trivial loads/stores just isn't as big of a deal on modern processors that are loaded to the gills with huge caches and deep pipelines. I guess I don't care that much about fomit-frame-pointer in the grand scheme of things, but I think enabling it in distributions was ultimately a mistake. If some software packages benefited enough from it, it could've just been done only for those packages. Doing it across the system is questionable at best...
michealliam320 2y ago
[dead]

by elteto 2y ago

yosefk 2y ago

it does present a conclusion. once the kernel supports .sframe it will be all-around superior to -fomit-frame-pointer, and a better default for distros to use.

audidude 2y ago
It does cause more memory pressure because the kernel will have to look at the user-space memory for decoding registers. So yes it will be faster than alternatives to frame-pointers, but it still wont be as fast as frame pointers.

Brian_K_White 2y ago

But does what you care about matter enough to be the default? Are you the majority? Evaluate "majority" this way: For every/any random binary in a distro, out of all the currently running instances of that binary in the world at any given moment, how many of those need to be profiled? There is no way the answer is "most of them". You have a job where you profile things, and maybe even you profile almost everything you touch. Your whole world has a high quotient of profiling in it. So you want the whole system built for profiling by default. How convenient for you. But your whole world is not the whole world. But it's not just you, there are, zomg thousands, tens of thousands, maybe even hundreds of thousands of developers and ops admins the same as you. Yes and? Is even that most installed instances of any given executable? No way. Or maybe yes. It's possible. Can you show that somehow? But I will guess no way and not even close.

audidude 2y ago
I regularly have users run Sysprof and upload it to issues. It's immensely powerful to be able to see what is going on systems which are having issues. I'd argue it's one of the major reasons GNOME performance has gotten so much better in the recent-past. You can't do that when step one is reinstall another distro and reproduce your problem. Additionally, the overhead for performance related things that could fall into the 1% range (hint, it's not much) rarely are using the system libraries in such a way anyway that would cause this. They can compile that app with frame-pointers disabled. And for stuff where they do use system libraries (qsort, bsearch, strlen, etc) the frame pointer is negligible to the work being performed. You're margin of error is way larger than the theoretical overhead.
- Brian_K_White 2y ago
  1% is a ton. 1% is crazy. Visa owns the world off just a 3% tax on everything else. Brokers make billions off of just 1% or even far less. 1% of all activity is only rational if you get more than 1% of all activity back out from those times and places where it was used. 1%, when it's of everything, is an absolutely stupendous collossal number that is absolutely crazy to try to treat as trivial.
  - ploxiln 2y ago
    Better analogy: you're paying 30% to apple, and over 50% in bad payday loans, and you're worried about the 3% visa/stripe overhead ... that's kinda crazy. But that's where we are in computer performance, there's 10x, 100x, and even greater inefficiencies everywhere, 1% for better backtraces is nothing.
    - audidude 2y ago
      Absolutely. We've gotten numerous double digit performance improvements across applications, libraries, and system daemons because of frame-pointers in Fedora (and that's just from me).
wbl 2y ago

baq 2y ago

fifty independent 1% performance drops nobody cares about compound to a ~40% reduction.

dralley 2y ago
No, that's not how it works. You don't stack 1% losses of the total application performance on top of each other just because your application uses 40 libraries.

josefx 2y ago

> 9X% of users do not care about a <1% drop in performance. Except Python got opted out of the frame pointer change due to benchmarks showing slowdowns of up to 10%. The discussion around that had the great idea of just adding a pragma to flat out override the build setting. So in the end that "%1" reduction claim only holds if everything even remotely affected silently ignores the flag.

audidude 2y ago
This is a bit of a mischaracterization of the Python side of things. They only opted out for 3.11 which did not yet have the perf-integration fixes anyway. 3.12 uses frame-pointers just fine.
- josefx 2y ago
  Any link to the fix or documentation about it? I could find added perf support but did not see anything about improved performance related to frame pointer use.
  - audidude 2y ago
    https://pagure.io/fesco/issue/2817#comment-826636 https://pagure.io/fesco/issue/2817#comment-826636 will probably get you started into the relevant paths. Python 3.12 was going to include frame-pointers anyway for perf to boot. So they needed to fix this regardless.

j16sdiz 2y ago

> 9X% of users do not care about a <1% The same could be said about any accessibility issue or minority language translations

jchw 2y ago
This comparison is pretty misleading. An accessibility issue prevents someone from being able to use software effectively. Not having localized text would have a similar impact. A ~1% performance impact on the other hand is the minuscule downside of improving debugging, profiling and error reporting for an entire OS. And that's not just a minority of users, as tons of software will automatically gather stack traces for bug reports. There's basically no downside to fixing accessibility issues or adding new language translations other than the work involved in doing so. (And yes, maintaining translations over time is hard, but most projects let them lag during development, so they don't directly hold anything back.) There is a rather glaring downside to this performance optimization, whose upside is sometimes entirely within run-to-run variance and can be blown away by almost any other performance tweak. It's clear the optimization has some upsides, but an extra register and saving some trivial loads/stores just isn't as big of a deal on modern processors that are loaded to the gills with huge caches and deep pipelines. I guess I don't care that much about fomit-frame-pointer in the grand scheme of things, but I think enabling it in distributions was ultimately a mistake. If some software packages benefited enough from it, it could've just been done only for those packages. Doing it across the system is questionable at best...

michealliam320 2y ago

[dead]