How is this an apples to apples comparison? Instantiating CRTPInterface with Implementation is no different than just calling DynamicImplementation::tick() directly, so why not benchmark that?
The cost of dynamic vs. static dispatch in C++ (2013)
11–20 of 33 posts
Re: The cost of dynamic vs. static dispatch in C++ (2013)
#12If you just want the number: dynamic is 6x slower.
That is with gcc -O2 (version 4.8) on an i7-4771 CPU
With -O3 the speedup is even more: 7.2x
on a Xeon E5-2690 (Sandy Bridge) with gcc 4.6.3 (same code generated) it was "only" 3x
Re: The cost of dynamic vs. static dispatch in C++ (2013)
#13In 2015 clang & gcc have a more or less working devirtualization feature that eliminates the virtual overhead in a simple benchmark such as this. The compiler sees all classes and knows that a particular interface is implemented by only one class, so it simply elides the virtual table lookup. Add that features such as speculative devirtualization that can remove a surprisingly large number of virtual calls in an esta…
If C++ will exist in 10 years from now
Apart from it being quite an interesting do-it-all type of language, solely seeing the huge amounts of existing codebases in 'slow' fields like production/manufacturing industries I am pretty sure it will.
Re: The cost of dynamic vs. static dispatch in C++ (2013)
#14If you just want the number: dynamic is 6x slower.
... with older compilers, without -fdevirtualize.
Re: The cost of dynamic vs. static dispatch in C++ (2013)
#15In 2015 clang & gcc have a more or less working devirtualization feature that eliminates the virtual overhead in a simple benchmark such as this. The compiler sees all classes and knows that a particular interface is implemented by only one class, so it simply elides the virtual table lookup. Add that features such as speculative devirtualization that can remove a surprisingly large number of virtual calls in an esta…
>If C++ will exist in 10 years from now, I predict 'virtual' to be just yet another legacy keyword. I really doubt that. Not so much because of the virtual call overhead, but because there's plenty of cases where you really want control over how your class objects and structs look in memory. Adding a vtable entry to every struct is something you really don't want in many cases.
A lot of people forget about small and embedded devices.
Re: The cost of dynamic vs. static dispatch in C++ (2013)
#16As the article demonstrates, in anything other than trivial microbenchmarks it's the inability to inline across a virtual call that will cost you. Inlining is the single most fundamental optimization for a modern C++ compiler. It enables the 0-cost abstractions for which C++ is rightly famous.
Re: The cost of dynamic vs. static dispatch in C++ (2013)
#17If you just want the number: dynamic is 6x slower.
Not a good summary.
1. If the static method is trivial enough, the compiler can inline it removing the need for a function call. In that case, a virtual function call for a single increment op is 6 times slower.
2. If you disable inlining for the static method, curiously it is 1.5 times slower than the virtual function call.
3. Newer compilers have devirtualize that the OP could not test but should be able to give much better than the 6x degradation.
Re: The cost of dynamic vs. static dispatch in C++ (2013)
#18How is this an apples to apples comparison? Instantiating CRTPInterface with Implementation is no different than just calling DynamicImplementation::tick() directly, so why not benchmark that?
The entire point of the benchmark is virtual calls vs templated static calls. Everything else is what should be controlled.
Re: The cost of dynamic vs. static dispatch in C++ (2013)
#19As the article demonstrates, in anything other than trivial microbenchmarks it's the inability to inline across a virtual call that will cost you. Inlining is the single most fundamental optimization for a modern C++ compiler. It enables the 0-cost abstractions for which C++ is rightly famous.
Why shouldn't it be possible to inline virtual calls? The CLR folks were complaining about this, too. But it seems rather straightforward to figure out the actual implementation that's commonly called and inline it, perhaps with a guard for uncommon cases. And I wouldn't be surprised if many apps end up with only a single actual implementation, so the entire virtual overhead can just be dropped.
Re: The cost of dynamic vs. static dispatch in C++ (2013)
#20As the article demonstrates, in anything other than trivial microbenchmarks it's the inability to inline across a virtual call that will cost you. Inlining is the single most fundamental optimization for a modern C++ compiler. It enables the 0-cost abstractions for which C++ is rightly famous.
Why shouldn't it be possible to inline virtual calls? The CLR folks were complaining about this, too. But it seems rather straightforward to figure out the actual implementation that's commonly called and inline it, perhaps with a guard for uncommon cases. And I wouldn't be surprised if many apps end up with only a single actual implementation, so the entire virtual overhead can just be dropped.
The problem is that unlike the CLR, static compilers have no idea about the common case. This technique works only when you have some information about how the different code paths are being used.