3 ms·
AAA dev here. The performance gains mostly come from designing data, not code. Factoring an array of structures into a structure of arrays and accessing linearl
by mwkaufma 9y ago
AAA dev here. The performance gains mostly come from designing data, not code. Factoring an array of structures into a structure of arrays and accessing linearly, e.g., makes better use of the processor cache and saturates throughput. Code optimization mostly gives us the confidence that there aren't unnecessary accesses or branches interleaved that might bust the cache.
- saosebastiao 9y ago> Factoring an array of structures into a structure of arrays and accessing linearly, e.g., makes better use of the processor cache and saturates throughput. This is an example of a provably correct optimization, and it's a shame that more compilers do not optimize this situation. Wouldn't it be awesome to model the data the way that makes sense for your domain and let the compiler worry about cache locality?
- zurn 9y agoJonathan Blow's Jai language lets you do this by annotating structs, along with some other assisted memory optimizations (pointer compression is another).
- AstralStorm 9y agoI suspect GCC could do it too for invisible or fully inlined symbols. This is possible in C99 and C++11 because type punning is forbidden in general. But that would need a special flag to specify incompatible internal ABI.
- mwkaufma 9y agoWell, in C memory is explicitly laid out, so it's not on the optimizer's menu, and in a dynamic language the runtime flexibility rules out most data-layout optimizations beyond occasionally coalescing a dictionary into a memory-offset-based buffer. There's some experimental game languages like JAI which include these semantics as a language primitive, but it's still declared rather than implied. Fundamentally, data layout is design because it depends on actual game content, and not just code; it's categorically different than code optimization.