The “C Is Efficient” Language Fallacy (2006)
scienceblogs.com
The “C Is Efficient” Language Fallacy (2006)
1–10 of 106 posts
Re: The “C Is Efficient” Language Fallacy (2006)
#2Loved the blog post. Too many people just love jumping the gun and saying that C/C++ are fast languages. I believe it was Chandler Carruth who said that C/C++ aren't performance languages, but rather languages that give you the largest control of your performance.
Re: The “C Is Efficient” Language Fallacy (2006)
#3I believe modern C/C++ has the restrict keyword which tells the compiler that pointers don't overlap. I'm not sure if this applies to arrays, but if so, it should be fairly trivial for a compiler to optimise parallel execution so that it matches Fortran or OCaml.
What am I missing?
Re: The “C Is Efficient” Language Fallacy (2006)
#4While I agree with the author about the main topic, the actual content does not illustrate the point well.
The author wrote a naive loop in a bunch of languages, and, got a faster result in OCaml (0.3 sec) than in C(0.8 sec). Right, but the code was a totally naive loop:
for (int i=0; i The fact that C has a bunch of libraries for vectorization of such code, or that there are million compiler directives that can speed that code a lot is somehow missing from the article.
So, the conclusion is that a compiled OCaml code is twice as fast as a naively written unoptimized loop in C.
Re: The “C Is Efficient” Language Fallacy (2006)
#5True, the efficiency argument is wrong. Thinking about your algorithm and knowing where you actually need to be efficient are far more important.
What I appreciate about C in particular is that it seems harder to "program by accident" than it is in most languages. C was my first language. After I learned C, I programmed in a higher level language for a while later before discovering that its runtime threw exceptions on 'array subscript out of bounds.' I discovered it by looking over someone else's shoulder in a lab. I realized then that I had just learned not to do that because C was so unforgiving.
We can argue whether the kind of discipline of thought that you gain from that experience is good or even useful today, but I suspect it is. It's different from learning how to do mental math in a world full of calculators - that's just raw mental exercise.
Re: The “C Is Efficient” Language Fallacy (2006)
#6as much as it's not part of the standard, __restrict__ allows limiting the effects of pointer aliasing in C/C++. [1]
Re: The “C Is Efficient” Language Fallacy (2006)
#7The post was published in 2006.
The claim that Fortran arrays are easier for the compiler to optimise than raw pointers in C/C++ may well be true. But I imagine that there has been progress on compiler technologies to address auto-vectorisation in C/C++ since the post was written (and since C99, C has the restrict keyword too). Can anyone comment?
Re: The “C Is Efficient” Language Fallacy (2006)
#8While I agree with the author about the main topic, the actual content does not illustrate the point well. The author wrote a naive loop in a bunch of languages, and, got a faster result in OCaml (0.3 sec) than in C(0.8 sec). Right, but the code was a totally naive loop: for (int i=0; i The fact that C has a bunch of libraries for vectorization of such code, or that there are million compiler directives that can spee…
That's right: the author wrote a bad argument because they made an invalid performance comparison: naive vs. sophisticated. Is there a C code that can be written that compiles to assembly which is as efficient (or more) than OCaml? Likely so, and if the author doesn't even attempt to do that, I don't find their argument convincing.
I recently learned that Knuth created a virtual instruction set (MMIX) specifically because he found that comparing algorithms with high level languages was too prone to problems. Using a direct instruction set that executes on a virtual machine means that algorithm analysis can focus on the algorithm.
Now, there is something to be said for languages which produce code that is nearly as efficient as the most efficient code you can produce with C, especially if it's easier to write it. But that's not the author's point.
Re: The “C Is Efficient” Language Fallacy (2006)
#9While I agree with the author about the main topic, the actual content does not illustrate the point well. The author wrote a naive loop in a bunch of languages, and, got a faster result in OCaml (0.3 sec) than in C(0.8 sec). Right, but the code was a totally naive loop: for (int i=0; i The fact that C has a bunch of libraries for vectorization of such code, or that there are million compiler directives that can spee…
The benchmark results are from several implementations of a longest common subsequence algorithm, the nested loops shown earlier are probably not part of that algorithm and were only meant to illustrate aliasing issues.
Re: The “C Is Efficient” Language Fallacy (2006)
#10Ehhhhh.... I can't help but think that it's never completely necessary to use totally unrestricted pointers in 'C'. Might be convenient, but very nearly certainly not necessary. Even in systems calls and library functions, it's possible to never dereference a pointer in an unconstrained manner. But you have to be prepared to reason rigorously about those constraints.
Noting that the semantics of array access semi-equate to pointer dereference is well beside the point.
This fellow's "for" loop: for (int i=0; i shows that you don't even have to have unrestricted pointer access to have bounds violations - what's "y[i-2]" when i==0?
'C' is not for everybody. It's a systems programming language. As the space of activities related to computers grows, there's no good reason to continue to erect a strawman about the language and set fire to it.