3 ms·
It's not just the loss of an architectural register, it's also the added cost to the prologue/epilogue. Even on x86_64, it can make a difference, in particular
by charleshn 3y ago
It's not just the loss of an architectural register, it's also the added cost to the prologue/epilogue.
Even on x86_64, it can make a difference, in particular for small functions, which might not be inlined for a variety of reasons.
- Asooka 3y agoIf your small function is not getting inlined, you should investigate why that is instead of globally breaking performance analysis of your code.
- Sesse__ 3y agoA typical case would be C++ virtual member functions. (They can sometimes be devirtualized, or speculatively partially devirtualized, using LTO+PGO, but there are lots of legitimate cases where they cannot.)
- kaba0 3y agoCPUs spend an enormous amount of time waiting for IO and memory, and push/pop and similar are just insanely well optimized. As the article also claims, I would be very surprised to see any effect, unless that more instructions themselves would spill the I-cache.
- charleshn 3y agoI've seen around 1-3% on non micro benchmarks, real applications. Aee also this benchmark from Phoronix [0]: Of the 100 tests carried out for this article, when taking the geometric mean of all these benchmarks it equated to about a 14% performance penalty of the software with -O2 compared to when adding -fno-omit-frame-pointer. I'm not saying these benchmarks or the workloads I've seen are representative of the "real world", but people keep repeating that frame pointers are basically free, which is just not the case. [0] https://www.phoronix.com/review/fedora-frame-pointer https://www.phoronix.com/review/fedora-frame-pointer