Sometimes C++ is faster [LWN.net]

Sometimes C++ is faster

Posted Jun 19, 2008 11:53 UTC (Thu) by cate (subscriber, #1359)
In reply to: Sometimes C++ is faster by nix
Parent article: Converting GCC to C++

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).

(Log in to post comments)

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.