Quote o' the Week: It’s [Not] Faster Because It’s C
Posted on October 12, 2010 by Tommy McGuireFrom Canned Platypus,
I’d even argue that the main reason kernel code tends to be efficient is not because it’s written in C but because it’s written with parallelism and reentrancy in mind, by people who understand those issues. A lot of code is faster not because it’s written in C but for the same reasons that it’s written in C. It’s common cause, not cause and effect. The most common cause of all is that C code tends to be written by people who have actually lived outside the Java reality-distortion bubble and been forced to learn how to write efficient code (which they could then do in Java but no longer care to).Smack!
There is some good advice there:
Focus on stability and features first, scalability and manageability second, per-unit performance last of all, because if you don’t take care of the first two nobody will care about the third.On the other hand, per-unit performance is a good tool to achieve stability, scalability, and manageability, so don't get carried away.
Compare results, not approaches.
This really depends. Have you seen the port of Git from C to Java? It contains some pretty nasty hacks to try to boost the performance of the Java code. As Torvalds says, Performance changes the way people use software.
While it may not be faster because it's C, C does facilitate thinking about performance for some architectures due to having a notation that matches the performance architecture fairly well. In my experience, once you have an application where most of the code is basically handrolling memory management a'la Firefox, you've reached an inflection point where C doesn't matter.
THAT, to me, is INTERESTING. We should be studying that inflection point carefully.
John "Z-Bo" Zabroski
I haven't seen the port of Git, but I have used C a good bit, and have noticed what seems to be an effect on my code when I am writing Java, for example. For one thing, I seem not to prefer heavily architected code; I also write very dense (for Java, as far as I know) code.
C is my type specimen for systems programming languages. Systems programming, as I define it, is primarily about resource management; resources are devices, memory, and in the limit, performance. (Rule of thumb: if your problem statement doesn't include "manage your own memory", it's not systems programming.)
So, I strongly agree with you that it's not faster because it's in C; rather, C is frequently faster because it is in some sense about managing things like speed.