Most C and C++ programmers say that performance is why you should use their language. This is clearly false, or rather, too simple by far.
The problem with this argument is that assembly language provides even more opportunities for performance tweaks than C/C++. There are plenty of C programs that have a little bit of assembly language sprinkled in at critical points for a speed boost.
If we need to choose a language to get the best performance, then, we will choose assembly language, and not C/C++.
Tradeoffs
The myth is that if performance is important, you should choose C/C++ as your programming language.
The reality is that choosing C/C++ compromises performance. Programmers can only justify the use of C/C++ (over assembly language) by considering non-performance factors.
For example, C and C++ are more portable than assembly language, and they provide the programmer with a higher level of convenience and abstraction. This increases programmer productivity.
The use of C/C++ can only be justified by considering tradeoffs in a high-dimensional space including performance, programmer productivity, and other variables. Of course if we are bringing productivity into the mix, it must be said that C and C++ really suffer in comparison to higher-level safe languages (e.g., Comparing Observed Bug and Productivity Rates for Java and C++ and many other studies).
The security tradeoff
Another way of looking at this is that even if you chose C/C++ “for performance,” you have also made a choice to accept the many tradeoffs that come with C/C++.
As a security researcher I’m particularly interested in tradeoffs that people make for more or less security. To be clear, I think that it is perfectly valid to opt for less security—we all do this, constantly. I agree with Linus, who said
To me, security is important. But it’s no less important than everything else that is also important!
That said, the data is clear and overwhelming: using C/C++ instead of a safe language is a massive security risk.
We are also entering an era in which attackers are increasing skilled and increasingly motivated. I think that it has become very hard to justify using C/C++ for military, automotive, and other security-critical applications today.
Is C really faster?
Performance is important, but we need to judge it by hard data, and the data is actually not clear on this.
For one thing, this is a moving target. Garbage collection algorithms are always improving. Incremental algorithms (which improve latency) are becoming more common, and concurrent algorithms take advantage of multi-core cpus, which are becoming more and more common.
People are inventing new programming languages all the time. New languages, overwhelmingly, are safe languages—languages in the Lisp family. Some of the new safe languages are designed with C-like control in mind. For example, Rust is a language that supports safe memory management without garbage collection. The trend is clear: the new languages are evolving and improving all the time, while C is standing still.
Hardware is also changing. The trend is toward many more cores, and ever-larger memories in a multi-level hierarchy with huge penalties for crossing levels. C does poorly here. C does not expose the memory hierarchy, and it is very hard to tackle concurrency by hand. In the long run, language and compiler support will be required to get the most out of modern hardware.