| |||||||||||||
|
| |||||||||||||
Sometimes C++ is fasterSometimes C++ is fasterPosted Jun 19, 2008 10:01 UTC (Thu) by nix (subscriber, #2304)In reply to: Sometimes C++ is faster by cate Parent article: Converting GCC to C++
My understanding is that what you say is true in modern compilers only for virtual functions defined in virtual base classes. Non-virtual-base class virtual function lookup requires only a single pointer dereference, from a fixed offset in the VMT, as does lookup of a virtual function defined in a class that has virtual bases, but not itself defined in that virtual base class or one of its ancestors. Virtual base classes are rare. This is one reason why. (Another reason is that, well, the designs that require virtual bases are generally either involuted or icky.)
(Log in to post comments)
Sometimes C++ is faster Posted Jun 19, 2008 11:53 UTC (Thu) by cate (subscriber, #1359) [Link] I'm not so sure that I understand your comment. My concern is about where compilers put the VMT table. If it is split from the data (as my (old) understanding and as I see in wikipedia), every class requires a pointer to the VMT, so there is two dereferences. The solution was to put some part (i.e. the first 10 virtual function pointer) into the class data, but because it cause more memory demand (i.e. event driven programming), I don't think it is default. Thus I like the C++ idea, if it bring to more development, especially on the optimization at program level (and not only at unit level).
Sometimes C++ is faster Posted Jun 19, 2008 18:06 UTC (Thu) by nix (subscriber, #2304) [Link] Oh, yeah, you have to jump to the VMT first, so two dereferences it is. Sometimes there are *more* than two, though (and sometimes there are none, as when the compiler can determine the static type of the instance: this happens more often than you might expect).
Usually C++ is faster Posted Jun 19, 2008 18:39 UTC (Thu) by ncm (subscriber, #165) [Link] Lots of falsehoods, misconceptions, and old myths to fix here. First, the STL containers and algorithms don't use virtual functions at all. Virtual functions aren't used much in modern C++ code, particularly in places where it matters how fast they are or aren't. This isn't so much because people worry much about how fast they are, but just because they are not often especially useful in low-level code where speed matters. Second, whatever overhead is associated with a virtual function call has very little to do with how many memory accesses occur, and everything to do with pipeline stalls. If the speed of a virtual function call matters, it's in a loop, and all the relevant memory is in cache. You might lose a cycle or two loading a memory word, then, but you lose a dozen or two branching through a pointer because the execution pipeline can't look ahead past that branch. If you used a function pointer in C, you would suffer precisely the same stall. (There are further complications I won't get into here.) So, as rules of thumb: (1) if it matters how fast a virtual function call is, compared to a regular function call, you're probably doing it wrong; and (2) a virtual function call is architecturally equivalent to calling through a C function pointer. How much do you use function pointers in C? That's about how much you should use virtual functions in C++. (If you're more used to Java... may heaven grant mercy on your soul.) In practice, the time spent doing virtual function calls has no measurable effect on the speed of a well-conceived C++ program.
|
|
||||||||||||