2 ms·
Wow, that's an impressive result. I wouldn't have guessed that L1-icache-misses were that significant of a time sink such that reducing them by 1/3 would be en
by nkurz 8y ago
Wow, that's an impressive result. I wouldn't have guessed that L1-icache-misses were that significant of a time sink such that reducing them by 1/3 would be enough to knock 15% off the total runtime.
Most of the time when I read about something that provides this much improvement on a major application, it turns out that the comparison isn't quite what it seems (as in, they are using -O0 as a baseline or some such). But from what I can tell, this is a genuine improvement over the best alternative.
Congratulations to the authors on a great job!
- josephg 8y agoYeah; wow thats a great result! Is BOLT used much in the wild? I'd love to see it applied to something like Chrome or Firefox. A double digit performance increase would be huge improvement for a browser's html/css parsers and rendering engine.
- cperciva 8y agoI doubt the improvement comes from icache misses. Rather, the improvement comes from avoiding pipeline flushes by reducing mispredicts, and said mispredict reduction also reduces icache misses.
- nkurz 8y agoI'm a little doubtful that reduced prediction error can be the main driver here. Hardware branch predictors are really good for anything that's predictable after a short learning period, so layout changes are only going to have an effect on prediction errors for the first couple iterations on a cold start. Can there really be hundreds of billions of cold starts? Maybe, but I suspect that optimizing the straight line code path to match the most common branch is the greater effect, since consecutive instructions are almost always going to be in cache. I'm still surprised the effect is this large, but I think it's a little more likely, and it does match the blog post.