The cost of dynamic vs. static dispatch in C++ (2013)
eli.thegreenplace.net
The cost of dynamic vs. static dispatch in C++ (2013)
1–10 of 33 posts
Re: The cost of dynamic vs. static dispatch in C++ (2013)
#2Re: The cost of dynamic vs. static dispatch in C++ (2013)
#3If C++ will exist in 10 years from now, I predict 'virtual' to be just yet another legacy keyword.
Re: The cost of dynamic vs. static dispatch in C++ (2013)
#4If you can use templates, the decision of which function to call can be done at compile time and you don't need virtual calls. Virtual calls are useful when the decision must be done at runtime.
Re: The cost of dynamic vs. static dispatch in C++ (2013)
#5In 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…
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.
Re: The cost of dynamic vs. static dispatch in C++ (2013)
#6In 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.
Re: The cost of dynamic vs. static dispatch in C++ (2013)
#7Re: The cost of dynamic vs. static dispatch in C++ (2013)
#8Re: The cost of dynamic vs. static dispatch in C++ (2013)
#9Why is the author referencing the Itanium C++ ABI? Isn't IA-64 an obsolete architecture that nobody uses? And then he gives examples with x86_64 and mentions his "i7-4771 CPU". Confusing.
Re: The cost of dynamic vs. static dispatch in C++ (2013)
#10Why is the author referencing the Itanium C++ ABI? Isn't IA-64 an obsolete architecture that nobody uses? And then he gives examples with x86_64 and mentions his "i7-4771 CPU". Confusing.
The C++ ABI that everyone (well, OK, the open source compiler toolchain ecosystem) uses nowadays on popular architectures was created for the Itanium [1], and so it bears its name. Itanium ended up having an impact in a weird, roundabout way :) [1]: https://mentorembedded.github.io/cxx-abi/abi.html
I remember early linux used to have lots of trouble running binaries across upgrades, because the C++ ABI kept changing and changing. Is that related?