Sometimes C++ is faster

For a long, long time? I think the gap was something like three years between Cfront and G++.
It might have felt like a long time then, but it really wasn't. :)

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

What you say is true, but it's mitigated in a few ways:

- None of this matters if the actual class of the object is known.  It only matters if you're
accessing a derived class via a base class pointer.

- If you're accessing several virtual members, the dereference to get the virtual function
table only needs to be done once.

- Virtual methods are rare in C++ (compared to e.g. Java).  I don't believe there are any at
all in the standard library, for example.

- Using less memory per object will improve your cache hit rate when you have more than a few
objects.


Here's a C++ benchmark.  "----" indicates a new file, to prevent too much being optimised
away:

struct base {
  virtual void foo() = 0;
};

struct derived: public base {
  void foo() {
    f1();
  }
};

----

int main()
{
  for (int i=0; i<100000000; ++i) {
    base* p = f2();
    p->foo();
  }
}

----

void f1() {
}

base* f2() {
  static derived d;
  return &d;
}


And here's a C version (well, actually it's still C++ but it's using a function pointer in the
struct rather than a virtual function):

struct base {
  typedef void(*foo_t)();
  const foo_t foo;

  base(foo_t f_): foo(f_) {}
};

----

int main()  // same as C++ version
{
  for (int i=0; i<100000000; ++i) {
    base* p = f2();
    p->foo();
  }
}

----

void f1() {
}

struct derived: public base {
  derived(): base(&f1) {}
};

base* f2() {
  static derived d;
  return &d;
}


Comparing these programs (x86, gcc 4.3.1, -O3) I find that the "C" version is about 20%
faster, or around 6 nanoseconds per call, on this 1 GHz VIA C3 machine.  That fraction would
clearly drop if you actually did something inside the virtual function.

> virtual function are a lot slower than the direct C equivalent.

How would you do in C then?  Because however it is, it can be done that way in C++.

More seriously though, you are saying that C++ does something like:

this->v_btl->virtual_call(params); right?

I would agree, but how would you do this any faster in C?  Recognize that you may not cast the
object pointer to a derived class, the compiler can't (necessarily) know that the conversion
is valid, and you could cast it in C++ if the programmer happens to know more than the
compiler.

i.e. if you were to do:

derived_virtual_impl(klass, params) in C, you could do:

obj->Derived::impl(params) in C++ and call the appropriate implementation directly.

Is there some neat-o technique I'm missing?

Sorry about replying twice but I missed this one too:

> C++ has also linker problem: dynamic linking is a lot slower (number of 
> function, but also because long names, which differentiate only at the
> end)

This is annoyingly true.  However, this has pretty much been rectified.

With recent binutils (I think 2.17.50 or later?) a new hash table format is used for ELF
dynamic binaries which significantly reduces the amount of string comparisons that must be
done in order to properly load a symbol.  Of course long symbol names still take a while to
load so it is important to reduce the amount of symbols used to the minimum necessary.  If you
have recent binutils you may already be able to see the fruits of this, you can use readelf -d
to see if you have a GNU_HASH section of a binary or a .so.

g++ since 4.0 has supported visibility for symbols, including symbols defined as part of C++
class and template generation, which takes care of that problem.  The problem is that C++
libraries must specifically support it, but support for that is growing.

prelinking provides benefits on top of that.  There are patches from Michael Meeks floating
around to allow a flag called -Bsymbolic which apparently also helps, but I don't really know
what it does beyond that, and it does not look like it will make it into binutils anyways.

But there's lots of work being done to rectify these problems, so it lookslike we're *almost*
getting to the point to where we can have our cake and eat it too. :)

However, do you really fancy writing all of your algorithms as macros?  Of course impressive
hacks are possible as one-offs.

The fundamental advantage (inlined templates over macros) is that the compiler knows what's
going on.  First, it can provide type checking, which with good design can prevent many usage
errors.  Second, it can provide type-based dispatching, enabling different algorithms to be
used for different data structures.  The optimal sort for a three-element array is
fundamentally different from that for one of unknown size.  The optimal sort for a linked list
is conceptually similar to that for an array, but an entirely different code sequence.  

Using template type matching, you can present the same interface for all these cases, and
generate appropriate code for each.  Try doing that with C macros, or even Lisp macros.

You might provide macros for all the cases, under different names, but you probably wouldn't,
because you could only use them locally.  Templates may be packaged cleanly and safely enough
to be generally usable, justifying more attention to their creation and distribution.

C++ may be faster in other places.  In a deep call chain, where each caller must check and
dispatch on the return value of each call, using exceptions well instead can make the code
both faster and much more compact and readable.  A taste of the difference may be seen in
numeric codes that rely on checking for Inf and NaN at the end of a computation; imagine
checking for all those conditions after each multiply!