3 ms·

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.

by Dwedit 3y ago

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.

kazinator 3y ago
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.
ack_complete 3y ago
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.
Taniwha 3y ago
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
cleak 3y ago
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.

by Dwedit 3y ago

kazinator 3y ago

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.

ack_complete 3y ago

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.

Taniwha 3y ago

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

cleak 3y ago

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.