Speed of virtual call in C# vs C++

Question

I seem to recall reading somewhere that the cost of a virtual call in C# is not as high, relatively speaking, as in C++. Is this true? If so - why?

Answer 1

A C# virtual call has to check for “this” being null and a C++ virtual call does not. So I can’t see in generally why a C# virtual calls would be faster. In special cases the C# compiler (or JIT compiler) may be able to inline the virtual call better then a C++ compiler, as a C# compiler has access to better type information. The call method instruction may sometimes be slower in C++, as the C# JIT may be able to use a quicker instruction that only copes with a small offset as it know more about the runtime memory layout and processor model then a C++ compiler.

However we are talking about a handful of processor instruction at most here. On a modem superscalar processor, it is very possible that the “null check” instruct is run at the same time as the “call method” and therefore takes no time.

It is also very likely that all the processor instructions will already in be the level 1 cache if the call is make in a loop. But the data is less likely to be caches, the cost of reading a data value from main memory these days is the same as running 100s of instructions from the level 1 cache. Therefore it is unlucky that in real applications the cost of a virtual call is even measurable in more then a very few places.

The fact that the C# code uses a few more instructions will of course reduce the amount of code that can fit in the cache, the effect of this is impossible to predict.

(If the C++ class uses multiple inherence then the cost is more, due to having to patch up the “this” pointer. Likewise interfaces in C# add another level of redirection.)

Answer 2

The original question says:

I seem to recall reading somewhere that the cost of a virtual call in C# is not as high, relatively speaking, as in C++.

Note the emphasis. In other words, the question might be rephrased as:

I seem to recall reading somewhere that in C#, virtual and non-virtual calls are equally slow, whereas in C++ a virtual call is slower than a non-virtual call...

So the questioner is not claiming that C# is faster than C++ under any circumstances.

Possibly a useless diversion, but this sparked my curiosity concerning C++ with /clr:pure, using no C++/CLI extensions. The compiler produces IL that gets converted to native code by the JIT, although it is pure C++. So here we have a way of seeing what a standard C++ implementation does if running on the same platform as C#.

With a non-virtual method:

struct Plain
{
    void Bar() { System::Console::WriteLine("hi"); }
};

This code:

Plain *p = new Plain();
p->Bar();

... causes the call opcode to be emitted with the specific method name, passing Bar an implicit this argument.

call void <Module>::Plain.Bar(valuetype Plain*)

Compare with an inheritance hierarchy:

struct Base
{
    virtual void Bar() = 0;
};

struct Derived : Base
{
    void Bar() { System::Console::WriteLine("hi"); }
};

Now if we do:

Base *b = new Derived();
b->Bar();

That emits the calli opcode instead, which jumps to a computed address - so there's a lot of IL before the call. By turning it back in to C# we can see what is going on:

**(*((int*) b))(b);

In other words, cast the address of b to a pointer to int (which happens to be the same size as a pointer) and take the value at that location, which is the address of the vtable, and then take the first item in the vtable, which is the address to jump to, dereference it and call it, passing it the implicit this argument.

We can tweak the virtual example to use C++/CLI extensions:

ref struct Base
{
    virtual void Bar() = 0;
};

ref struct Derived : Base
{
    virtual void Bar() override { System::Console::WriteLine("hi"); }
};

Base ^b = gcnew Derived();
b->Bar();

This generates the callvirt opcode, exactly as it would in C#:

callvirt instance void Base::Bar()

So when compiling to target the CLR, Microsoft's current C++ compiler doesn't have the same possibilities for optimization as C# does when using the standard features of each language; for a standard C++ class hierarchy, the C++ compiler generates code that contains hard-coded logic for traversing the vtable, whereas for a ref class it leaves it to the JIT to figure out the optimal implementation.

Answer 3

For JIT compiled languages (I don't know if CLR does this or not, Sun's JVM does), it's a common optimisation to convert a virtual call which has only two or three implementations into a sequence of tests on the type and direct or inline calls.

The advantage of this is that modern pipelined CPUs can use branch prediction and prefetching of direct calls, but an indirect call (represented by a function pointer in high level languages) often results in the pipeline stalling.

In the limiting case, where there is only one implementation of the virtual call and the body of the call is small enough, the virtual call reduced to purely inline code. This technique was used in the Self language runtime, which the JVM evolved from.

Most C++ compilers don't perform the whole program analysis required to perform this optimisation, but projects such as LLVM are looking at whole program optimisations such as this.

Answer 4

I guess this assumption is based on JIT-compiler, meaning that C# probably converts a virtual call into a simple method call a bit before it is actually used.

But it's essentially theoretical and i would not bet on it !

Answer 5

The cost of a virtual call in C++ is that of a function call through a pointer (vtbl). I doubt that C# can do that one faster and still being able to determine object type at runtime...

Edit: As Pete Kirkham pointed out, a good JIT might be able to inline the C# call, avoiding a pipeline stall; something most C++ compilers cannot do (yet). On the other hand, Ian Ringrose mentioned the impact on cache usage. Adding to that the JIT itself running, and (strictly personally) I wouldn't bother really unless profiling on the target machine under realistic workloads has proven the one to be faster than the other. It's micro-optimization at best.