Hacker News Reader

Comment by CyberRabbi | Hacker News Reader

Are direct calls really all that much faster than indirect calls on current x86 archs? I was under the impression that it’s more or less the same on the current generation of CPUs. Those CPUs do a decent job of branch predicting indirect calls, especially in a micro benchmark loop. The BTB generally works well.

View on HN

The article has benchmark results that quantifiably establish direct calls outperforming indirect calls.

It’s not an apples to apples comparison unfortunately. He’s using custom assembly for the direct call benchmark but C code for the indirect benchmark.

The C code contains no optimization annotations either, the compiler could be inlining the indirect benchmark and/or devirtualizing the indirect call itself.

No. That is not how shared libraries work.

The benchmark quantifiably shows that direct calls are faster than indirect calls, which was your original question. Could a hypothetical C compiler transform an indirect call to a shared library into a direct call? Maybe, but that is different from your original question as to the performance of direct vs. indirect calls on modern x86 architectures which this benchmark shows is not the same.

Unless he uses the same custom assembly except with an indirect call, it’s not a good comparison. We can’t be sure the increase in runtime is due to the indirect call.

All the details are right in the article as well as a link to a git repo so I'm not sure what there is to speculate about. If you have an issue with the actual benchmark you can certainly point it out, but otherwise you're basically asking us to restate the contents of the article when the article does a much better job of explaining these details.

Hmm I’m not sure you’re responding to what I’m saying. The C code is not an apples to apples comparison with the custom assembly when comparing the speed of an indirect call to a direct call. Do you deny that?

Yes I do deny that, especially since the article literally addresses this issue explicitly and takes care to avoid that, along with a git repo that you can use to verify this for yourself. If you have a specific criticism to make then you should go ahead and point it out in a non-vague manner instead of speculating.

> especially since the article literally addresses this issue explicitly and takes care to avoid that

Can you cite where in the article it addresses the fact that the assembly snippet is not an apples to apples comparison with the C code?

> If you have a specific criticism to make

Pointing out that the assembly is not an apples to apples comparison with the C code is a specific criticism.

Reply on news.ycombinator.com