You are hereAnd again: Is C++ really faster?

And again: Is C++ really faster?


By Gerd Riesselmann - Posted on 04 November 2006

I was pointing to articles about if low level optimization really makes sense and if C++ is really faster than higher level languages several times. But of course this will be a never ending debate, and it still continues. This time C and C++ should be the best languages for higher level mathematics problems. Unfortunately this is not the case.

The author argues that

C and C++ just aren't productive languages. It takes 2-4 times as long to implement something in these languages than in a very high level language like Ruby. The resulting code is harder to read, harder to maintain, and harder to port.

I totally agree with this, and like the author I think this is the reason why C++ looses popularity.

I disagree however when the author opposes to high level language features like a garbage collection. He argues that this will have impact on speed, which is the last outstanding C and C++ have to offer:

C and C++ are never going to disappear. Why? Because there are classes of programming problems that are still and will always be CPU bound and there is still no language as fast as C or C++ for these problems. I highly doubt that there ever will be.

I'm talking about things like: scientific number crunching, game/simulation physics, raytracing, real-time 3d graphics, audio processing, codec implementation, high-speed network packet routing, evolutionary computation (my personal favorite :), and of course implementing all these high-level languages' runtimes. There are also problems like OS and hardware driver implementation where you need something "close to the metal" that can interact closely with and even embed assembly language. C is basically shorthand for assembler, which is why it's the preferred language for that kind of thing.

While the second part of the argument may be true (I'm not that into C and Assembler since I sold my C64 back in 1985), this would be a rather - well - boring niche for the powerful language C++ is. For the first part, this is plain wrong, as it was already stated in the comments.

A more detailed reply can be found at Good Math, Bad Math - and it is the same as for low level optimization: Compiles do a much better job than people can do. If they are provided with the necessary information, which due to their pointer based nature is a problem in C and C++:

So for modern systems, writing an efficient program is sort of a partnership. The human needs to careful choose algorithms - the machine can't possibly do that. And the machine needs to carefully compute instruction ordering, pipeline constraints, memory fetch delays, etc. The two together can build really fast systems. But the two parts aren't independent: the human needs to express the algorithm in a way that allows the compiler to understand it well enough to be able to really optimize it.

And that's where C and C++ fall down. C and C++ are strongly pointer-based languages. The real semantics of almost anything interesting end up involving pretty much unrestricted pointers. In C and C++, there's no such thing as an array - there's just pointers, which you can subscript and a shorthand for pointer arithmetic and indirection(x[n] in C/C++ is the same thing as *(x+n).)

That pointer based nature means that in a C or C++ program, it's very hard for a compiler to figure out what things are independent. It comes down to a problem called alias detection. Alias detection is identifying when two variables might be referencing the same location. Alias detection becomes a horrific mess in the presence of unrestricted pointers.