2 ms·
> Memory layout is most definitely important just because memory accesses have such a high latency Indeed, but that’s not what the video is about. They don’t d
by Const-me 5y ago
> Memory layout is most definitely important just because memory accesses have such a high latency
Indeed, but that’s not what the video is about. They don’t discuss how to implement cache friendly data structures.
They tell how small random differences introduced by the size of environment variables, and linking order, affect performance. The statement seems to base on that article: https://users.cs.northwestern.edu/~robby/courses/322-2013-spring/mytkowicz-wrong-data.pdf https://users.cs.northwestern.edu/~robby/courses/322-2013-sp... The problem with that article, it’s entirely based on one synthetic test. And that test is rather unnatural IMO, that’s not how people are usually writing performance-critical code.
- anarazel 5y agoI see such effects somewhat regularly, albeit not at an overall impact of 40%. With precise code layout having the biggest impact, leading to different L1i and iTLB hit ratios. Of course that requires execution costs to be well spread around, rather than allow in a small amount of code. In my case, working on postgres, this is partially caused by the old school recursive row-by-row query executor model...
- Const-me 5y agoI know it can happen, but I would expect the result to be a couple percepts. OTOH, I did observe up to 20% randomness based on other choices made by optimizer, compiler and linker. In my experience, the main source was different decisions what to inline, especially for release builds with LTO/LTCG. For me, a good workaround was compiler-specific forceinline/noinline function attributes. However, my C++ code is probably very different from what's in postgres. I usually write and optimize manually vectorized and OpenMP parallelized numeric stuff, FP64 or FP32, doing little to no I/O.