4 ms·

https://docs.kernel.org/x86/orc-unwinder.html https://docs.kernel.org/x86/orc-unwinder.html (which I found when looking up ORC, as mentioned in this thread) has

by evmar 4y ago

https://docs.kernel.org/x86/orc-unwinder.html https://docs.kernel.org/x86/orc-unwinder.html (which I found when looking up ORC, as mentioned in this thread) has some stats for the Linux kernel on the cost of frame pointers: "5-10%" and "3.49% more cache misses with framepointer enabled and 6.59% more cycles". Between this, the various sorts of C language safety checks compilers have been slowly adding, and all the spectre-related defenses, it really does feel like performance is getting slowly consumed by a series of single-digit percentage tweaks.

mepian 4y ago
It's just the time to pay the piper finally arriving, the computer industry ignored security in favor of performance for far too long.
- nullc 4y ago
  > the computer industry ignored security in favor of performance for far too long Doesn't including an explicit, predictable, frame pointer make life moderately easier for shell code?
bravetraveler 4y ago
I agree -- it's easy to think that a few percent here/there don't hurt, but there's no global context on this. Team A takes away ~4% here, B goes on to do ~3%, and so on and so forth. In only five of these, and consider the chains of Pythonic imports you've seen for example, you've lost roughly a quarter of your performance. (grant me an additive/compounding? nature) This is assuming that the measurements taken in a vacuum even hold up to reality. I've seen reports for misc. other things in the 20% range, so my confidence is remarkably low. I'm not against making it easier, but I don't think everyone always need to be ready for profiling. Making opting in easier lets us ignore the hand-wavy numbers. edit: To add, the simplification of this performance cost down to percentages completely ignores scale. It's a deceptive statistician's trick. Your favorite browser accidentally releasing a debug/verbose-logging version that consumed in the range of 1-10% more power globally would be significant.
- ilyt 4y ago
  And each 2-3% reduction is reason that the following 2-3% reduction asks "the previous one was accepted, why not accept this one?"

by evmar 4y ago

mepian 4y ago

It's just the time to pay the piper finally arriving, the computer industry ignored security in favor of performance for far too long.

nullc 4y ago
> the computer industry ignored security in favor of performance for far too long Doesn't including an explicit, predictable, frame pointer make life moderately easier for shell code?

bravetraveler 4y ago

I agree -- it's easy to think that a few percent here/there don't hurt, but there's no global context on this. Team A takes away ~4% here, B goes on to do ~3%, and so on and so forth. In only five of these, and consider the chains of Pythonic imports you've seen for example, you've lost roughly a quarter of your performance. (grant me an additive/compounding? nature) This is assuming that the measurements taken in a vacuum even hold up to reality. I've seen reports for misc. other things in the 20% range, so my confidence is remarkably low. I'm not against making it easier, but I don't think everyone always need to be ready for profiling. Making opting in easier lets us ignore the hand-wavy numbers. edit: To add, the simplification of this performance cost down to percentages completely ignores scale. It's a deceptive statistician's trick. Your favorite browser accidentally releasing a debug/verbose-logging version that consumed in the range of 1-10% more power globally would be significant.

ilyt 4y ago
And each 2-3% reduction is reason that the following 2-3% reduction asks "the previous one was accepted, why not accept this one?"