> A switch statement with many cases can be compiled as a jump table (fast, O(1), but requires a full table load and indirect jump) or as a cascade of compares (slower per-case but better branch prediction if one case dominates).
Switch case is the workhorse of a lexer, parser and execution engine. Lots of them over enums.
This was all mis-optimized for years thanks to Spectre/Meltdown changing how the actual runtime of pre-fetch and speculation used to work.
All my work on CGOTO was made irrelevant by the CPU advances, only to become relevant again when fetch speculation got nerfed.
The indirect call scenario is a bit more interesting, because the JVM has an amazing paper about interface dispatch caches [1] on how to do it runtime instead of compile time.
The PGO is still useful, but not unless you can predict the workload you're going to have - Benchmarketing with a TPC benchmark is a good situation for it.
If you have consistent hardware, tuning an OLTP system for the hardware is much more interesting. Going back in the memory hole, Yahoo used to have a Jeremy Cole build of Mysql which was specially optimized for the raid disk layout that was in production (ZFS came by to fix those issues directly).
We are building our compiler and the entire LLVM toolchain with PGO, and it gives a solid 20..30% improvement in build speed*. At the same time, building ClickHouse with PGO does not give any meaningful improvement.
We've tried PGO with the Evolution engine every major Visual Studio release for as long as I can remember and each time we fail to measure a significant performance increase -- certainly not anything worth the substantial time and effort required to do it regularly.
Our most recent test of LTCG was actually interesting because it seemed to move the needle enough to measure (but not enough to suffer). It appeared as though it optimized the vast majority of the code for size (inlining sparingly) and we speculate that the improvements to cache usage were the reason we saw improvements.
> A switch statement with many cases can be compiled as a jump table (fast, O(1), but requires a full table load and indirect jump) or as a cascade of compares (slower per-case but better branch prediction if one case dominates).
Switch case is the workhorse of a lexer, parser and execution engine. Lots of them over enums.
This was all mis-optimized for years thanks to Spectre/Meltdown changing how the actual runtime of pre-fetch and speculation used to work.
All my work on CGOTO was made irrelevant by the CPU advances, only to become relevant again when fetch speculation got nerfed.
The indirect call scenario is a bit more interesting, because the JVM has an amazing paper about interface dispatch caches [1] on how to do it runtime instead of compile time.
The PGO is still useful, but not unless you can predict the workload you're going to have - Benchmarketing with a TPC benchmark is a good situation for it.
If you have consistent hardware, tuning an OLTP system for the hardware is much more interesting. Going back in the memory hole, Yahoo used to have a Jeremy Cole build of Mysql which was specially optimized for the raid disk layout that was in production (ZFS came by to fix those issues directly).
[1] - https://dl.acm.org/doi/10.1145/504311.504291
We are building our compiler and the entire LLVM toolchain with PGO, and it gives a solid 20..30% improvement in build speed*. At the same time, building ClickHouse with PGO does not give any meaningful improvement.
* https://github.com/ClickHouse/ClickHouse/pulls?q=is%3Apr+sta...
We've tried PGO with the Evolution engine every major Visual Studio release for as long as I can remember and each time we fail to measure a significant performance increase -- certainly not anything worth the substantial time and effort required to do it regularly.
Our most recent test of LTCG was actually interesting because it seemed to move the needle enough to measure (but not enough to suffer). It appeared as though it optimized the vast majority of the code for size (inlining sparingly) and we speculate that the improvements to cache usage were the reason we saw improvements.