I 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...
I 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.
In my case, working on postgres, this is partially caused by the old school recursive row-by-row query executor model...