Compile-Time Improvements in LLVM 23
21 points by MaskRay
21 points by MaskRay
so many small improvements, really goes to show how much of a grind optimization can be
Same with SQLite release notes — they tout small improvements to specific subroutines, but man it adds up over time.
My understanding is that this is how the Stockfish chess engine improves as well. If you can change something in the engine to make the ELO go up even a tiny bit, then it’s a success.
This makes me think I should try out replacing a function arguments representation (in a work project) from being (fnPtr, numArgs, ...offsetToArgNode) into just (fnPtr, offsetToLastArg) and calculate the number of arguments by checking the preceding nodes' output offset: if it matches the offset to the function then they're an argument, otherwise it's an argument's argument of some kind.
It'd save me some space in the spill data array and make function node spills statically sized, at the cost of making argument gathering a little more expensive.
Sounds like a data-oriented design approach: it is cheaper to calculate than to memoize.
Yup, I'm sort of a data-oriented design zealot :) That being said it's entirely possible that the tradeoff wouldn't be worth it in this case: my graph is already split into a three-part Struct-of-Arrays and the spill-array: the spill-array is much smaller (generally in thousands or at most tens of thousands, while the main SoA grows to 100s of thousands), its contents are reused (so a node doesn't need to add more spill if it finds the data it needs already in the array) and a good bit of the time is spent in preallocating the argument arrays: if I didn't know the argument array size beforehand I'd end up possibly reallocating or at least overallocating, costing some extra time.
That being said, it's still worth a try.