Hacker News Reader

Comment by Dwedit | Hacker News Reader

Branch prediction of Virtual Calls has traditionally been to look at the address of the calling instruction, and assume it will be the same target as last time.

But the real penalty for using Virtual Calls is the potential loss of inlining. It depends on how smart your compiler is.

View on HN

Modern CPUs support indirect branch prediction based on global branch history, they've advanced past simple predict-not-taken or predict-last for indirect calls. Intel has been doing it since Haswell.

It's kind of worse than this - a virtual function call is a load (from the object) to get the vtable pointer followed by a load from an offset of that followed by a subroutine call from that pointer - it's kind of the worst thing you can do in a high performance microachitecture - because you're going to predict that branch (call) and often get it wrong, but you wont know you got it wrong until you've done the two loads (which can't be parallelised, because the address of one depends on the other). By the time you've resolved this you may be throwing away tens or a hundred instructions from your pipe if the prediction was wrong

Virtual function APIs have to be designed such that they don't suffer from lack of inlining.

E.g. if you're making a graphics display driver, don't have objref->putpixel(x, y) as your only virtual function, which has to be called thousands of times to draw a line or millions to fill an area.

Cache coherency and better prediction is the main reason I went down this path in the first place. Sorting by the function to be called rather than just a grab bag of arbitrarily ordered `.Update()` calls (which is what happens in Unity, being my main reference point for this) is going to give some speed gains, even with the indirection still there. Of course eliminating some indirection is usually a win.

Reply on news.ycombinator.com