The "C is Efficient" Language Fallacy

Reminds me of The Practice Of Programming, by Kernighan and Pike, a truly excellent book. They cover some of the bum steers of C efficiency quite well there. A classic.

While I don't have enough experience in really low-level tuning, I know that sometimes people get so focused on optimizing their current implementation that they fail to see that their overall design has trapped them in a local maxima. Problems like inappropriate algorithms are usually more obvious in higher level languages, because there's less detail obscuring them. That stuff needs to be right before getting to fine tuning. (Prototyping in another language first helps.)

C and C++ are quite fast locally, but sometimes that works against being fast overall.

I disagree with some of the Authors points.

The language is a tool, the efficiency of it really depends on how the programmer who designs and implements a program. You can have a horrible coder write something in C that would be very slow and inefficient, and given the same problem to good programmer and you can arrive at a faster and more efficient result using a bash script.

The reason why lot of people (including my self) believe that C/C++ is a high performance language is not because it fast for all applications, but gives the programmer more control instead of leaving all the fine details to the compiler to second guess. (@tptacek's reasons are perfect for this).

I have a friend at Intel who works on their realtime raytracing efforts and he swears by C/C++. Indeed, his arguments mirrors yours and go even farther. There's all sorts of magic you can play when you've got access to the actual bits and bytes. For starters, they do things like stash data in the low-precision bits of floats and the lower three bits of pointers. I wholeheartedly concur with his opinion that in raw performance terms, C/C++ is the fastest.

The problem with his argument and yours is that C is NOT faster for The Rest of Us because it it amounts to premature optimization just by virtue of using it. And because it takes so much effort to get C code to just work, the WHOLE program ends up being slower than the corresponding code in Haskell, OCaml, or perhaps even CLisp. Having worked my last job in a company where the programmers preferred C to C++ and C++ to Python, it startles me how utterly slow our system was. And ditto for the previous job.

At my first place, we had a streaming video server that had blindingly fast compression routines, but it was all held up by a UI loop that harked from the prototype days. Thus the argument that C/C++ is/are the best languages for fast code is moot. It is only the fastest if you've all the time in the world to write it.

DSP is one domain where performance of a tiny part of the code (say 1%) is far, far more important than everything else. If you need to apply a filter to remove high frequencies, or if you need a Fourier transform, no high-level tuning or special algorithm will cut it: you need the filter or the transform, even if it's very costly. The bottleneck is real and unavoidable.

I work in data acquisition and in this domain C/C++ is king. The raw number-crunching is essential (for our applications anyway), and any bonus that can be had from SSE operations, cache locality, loop unrolling, software pipelining, etc. can have a major impact on the overall performance. Assembly is still common on DSP processors and the like (they typically provide a special instruction set). Even in C++, we tend to use the bit-twiddling and pig disgusting optimization hacks that low-level access provides :)

Some people use higher level tools such as LabView but the performance is a huge step down. It's OK for prototyping and learning.