3 ms·
> So you are questioning the effect of direct threading code? No, cos I said "the benchmarks speak for themselves". But I am trying to understand why it's bett
by _a_a_a_ 3y ago
> So you are questioning the effect of direct threading code?
No, cos I said "the benchmarks speak for themselves". But I am trying to understand why it's better and under what circumstances.
- kaba0 3y agoI meant it in terms of whether your question is about the reordering or the direct threading vs naive switch-loop.
- _a_a_a_ 3y agoThe direct threading is what interests me. From a link provided above by @ghusbands https://eli.thegreenplace.net/2012/07/12/computed-goto-for-efficient-dispatch-tables https://eli.thegreenplace.net/2012/07/12/computed-goto-for-e... "...and the goto version is 25% faster than the switch version... Comments inside the CPython implementation note that using computed goto made the Python VM 15-20% faster" (Which isn't the 2-4x speed up that you found. Maybe you meant 20-40%?). In that link they say that part of the reason is because of the bounds checking which is automatically done by the switch statement. What I'm struggling with which is no doubt down to my lack of knowledge, is why it should be significantly faster (if you take out or disable the bounds checking added by the switch). I can see there would be some advantage in spreading out the jumps so the branch predictor could work a bit better, but I am surprised at the speed up. I guess mispredicted branches are so expensive that doing just a little bit better could account for the difference, but I am trying to understand it.