TITLE: Stroustrup on C++ performance

(Newsgroups: comp.lang.c++, 29 Sep 99)


STROUSTRUP: bs@research.att.com (Bjarne Stroustrup)

> >But we don't take "two gurus" and see what they can produce starting
> >from scratch. We build on a couple of decades of experience and tools.
> >That was a key reason behind Cfront generating C: That way, C++ users
> >could immidiately and directly benefit from the good work of C compiler
> >writers. In real life, C and C++ tend to share a code generator and the
> >critical differences are in the work the compiler front-end performs
> >before calling the code generator and optimizer. There are extra work
> >and extra opportunities for optimization in a C++ front-end compared
> >to a C front-end.


QUINN: gerryq@indigo.ie (Gerry Quinn)

> In the real world, there are many extra opportunities for a programmer
> to inadvertently write slow code in C++ compared to C.  I suspect this,
> rather than compiler quality, is the deciding factor in the average
> speed of equivalent programs written by equivalent programmers in the
> two languages.


STROUSTRUP:

You seem to me making the assumptions that equivalent programs differ in
speed and that the C++ versions are slower. I think both assumptions are
wrong. The latter assumption is typically supported by anecdotal evidence
(that is no evidence) only. There is no shortage of stories about how
some program ran faster when re-done in a C style; nor is there any
shortage of stories about how some program ran faster when re-done in C++.

There are amble opportunities for writing "inadvertently slow code" in
both languages. In my opinion, most performance problems occur when people
lose sight of the overall strcture of a system. The cause of the worst
maintenance problems have the same root cause.

To get a rational discussion I think we need to compare actual code and
coding styles in detail. We need to compare it for ease of writing, ease
of maintenance (i.e. ease of understanding and ease of change), typical
errors, run-time speed, and memory consumption. To make genuine progress,
we must measure and quantify.

In particular, we need to examine the styles used in the implementation
of popular libraries and in the style of use they encourage. In my opinion,
most of the obvious inefficiencies occur in libraries and in inappropriate
use of libraries.

As a small example of such a comparison, have a look at my paper "Learning
Standard C++ as a New Language". It can be downloaded from my home pages.
That paper discusses the complexity and cost of styles in the context of
education, rather than attempting the much more ambitious task of language
comparison. However, it directly addresses some myths.

[ See http://www.research.att.com/~bs ]