The "C is Efficient" Language Fallacy (2006) • Hacker News Board

Re: The "C is Efficient" Language Fallacy (2006)

#31

Post by CountHackulus » Mon, Jan 09, 2012, 2:32 PM UTC

unwind wrote: post #2

This is old (2006), and seems to base its argument around the problems with unrestricted pointers in C, that cause aliasing. As of C99, of course, C has the "restrict" keyword which allows pointers to explicitly be declared to not alias, thus enabling all these optimizations in C, too.

In addition to that, if you're using the Intel compiler, then you can say

   #pragma ivdep

Which tells the compiler that the loop you're writing doesn't have any vector dependencies. Or -fno-fnalias to say that none of the arguments you're passing to a function are aliased.

Seems like pretty reasonable ways around the problem. Not to mention things like OpenMP.

Re: The "C is Efficient" Language Fallacy (2006)

#32

Post by wickedchicken » Mon, Jan 09, 2012, 2:33 PM UTC

Peaker wrote: post #22

zvrba wrote: post #18

C and C++ are efficient for general-purpose programming, if you know how to use them. C is here to stay because it is lingua franca of the computing world: OS APIs are defined in terms of C functions, and I know of no libraries in wide-spread use that do not offer a C or C++ interface. People otherwise rightfully challenge his conclusions. There's a funny comment there about matlab: "MATLAB struck me as being the wro…

Matlab may be a pretty bad language, but it gives access to a huge (and growing) body of existing code.

If you're an engineer (like an engineer engineer, not a software engineer) 90% of the time matlab has some module built-in or for sale that simply solves the problem you have. For example: http://www.mathworks.de/products/dsp-system/demos.html?file=...

The code to construct an LMS filter (http://en.wikipedia.org/wiki/Least_mean_squares_filter#LMS_a...) is effectively one line:

   h = adaptfilt.filtxlms(L,muW,1,Hhat);

Re: The "C is Efficient" Language Fallacy (2006)

#33

Post by jpdoctor » Mon, Jan 09, 2012, 2:35 PM UTC

> Modern architectures have reached the point where people can't code effectively in assembler anymore

Someone should inform the guys over at ffmpeg that the jig is up.

Re: The "C is Efficient" Language Fallacy (2006)

#34

Post by attractivechaos » Mon, Jan 09, 2012, 2:40 PM UTC

The longest common substring problem (LCS) can be solved in O(n^2) time using dynamic programming, not O(n^3) as is stated by the author of that post. If the author is unable to get the basic fact right, I can hardly trust his benchmark. Also, I question the author's skill in C/C++: in my experiences, C is consistently faster than Java for such tasks and C++ is nearly as fast as C as long as we use it the right way. If we look at the computer benchmark games, OCaml never beats C in terms of speed. I doubt the conclusion was much different in 2006. The author should released the source code; otherwise the benchmark tells us nothing but his incapability in programming.

EDIT: in his comments to another commenter, the author was saying this: "[The OCaml compiler] could do some dramatic code rewriting that made it possible to merge loops, and hoist some local constants out of the restructured merged loop." A good C programmer should be able to do all the above simply by instinct. The author was not good enough. I buy the argument that being really good at C/C++ is more difficult than at other languages, but this is not the same thing as arguing C is inefficient.

Re: The "C is Efficient" Language Fallacy (2006)

#35

Post by microtonal » Mon, Jan 09, 2012, 2:40 PM UTC

jrockway wrote: post #14

nickolai wrote: post #9

Umm, yes C/C++ will not parallelize your code for you, whereas Language XYZ will. Im not sure how this is an argument against C/C++ being effective. C/C++ will not parallelize your code by design. It's was never meant to. I'd never blame my stick-shift car for not changing gears by itself - thats the first reason I didnt buy an automatic in the first place! If your matrix manupuilation code performance becomes an iss…

You're missing the point. The target demographic for this article is someone who is not a computer scientist. He's someone who doesn't have time to deal with thread libraries and low-level matrix operations. He just needs to crunch his data quickly so that he can publish his valuable research. This person reads the same blog articles that computer scientists do, and comes to the conclusion that "I should learn C++ fo…

Except that there are fine high-level matrix libraries, optimization libraries, etc. for C/C++. I needed an parameter estimator for maximum entropy models that was efficient for training rankers (e.g. for parse disambiguation, fluency ranking, etc.), that also had good support for feature selection. I just used an off-the-shelf optimizer (liblbfgs), implemented calculation of the objective and gradients, plus various feature selection methods.

Within no-time, we had an extremely fast estimator, that could also help answering my research question (what are the most discriminative features in our models).

Let me push this point somewhat further: C is a very simple language. It's something that someone with a certain level of intelligence can fairly quickly pick up. There is also a wealth of excellent libraries available. The problem with 'use high-level, the compiler/interpreter will take care of it' is that those languages are either a lot more complex (Haskell, OCaml) or a lot slower (Python, Perl, Ruby). In the latter case, you will end up implementing modules in C anyway.

Re: The "C is Efficient" Language Fallacy (2006)

#36

Post by stonemetal » Mon, Jan 09, 2012, 2:46 PM UTC

z0r wrote: post #6

gizzlon wrote: post #3

For me, the blinking and moving ads completely invalidate this site..

Because I've read this blog before, I can point you to this: http://scienceblogs.com/goodmath/2010/07/seed_conflicts_of_i... Don't blame the author

Given that you might like his new site better.

http://scientopia.org/blogs/goodmath/

Re: The "C is Efficient" Language Fallacy (2006)

#37

Post by MichaelSalib » Mon, Jan 09, 2012, 2:48 PM UTC

microtonal wrote: post #35

jrockway wrote: post #14

Earlier quoted context omitted.

You're missing the point. The target demographic for this article is someone who is not a computer scientist. He's someone who doesn't have time to deal with thread libraries and low-level matrix operations. He just needs to crunch his data quickly so that he can publish his valuable research. This person reads the same blog articles that computer scientists do, and comes to the conclusion that "I should learn C++ fo…

Except that there are fine high-level matrix libraries, optimization libraries, etc. for C/C++. I needed an parameter estimator for maximum entropy models that was efficient for training rankers (e.g. for parse disambiguation, fluency ranking, etc.), that also had good support for feature selection. I just used an off-the-shelf optimizer (liblbfgs), implemented calculation of the objective and gradients, plus various…

C is a very simple language.

It is? Out of curiosity, did you know about all the undefined behaviors described at http://blog.llvm.org/2011/05/what-every-c-programmer-should-... and did you understand how your C compiler takes advantage of them before you wrote that statement?

Re: The "C is Efficient" Language Fallacy (2006)

#38

Post by kstenerud » Mon, Jan 09, 2012, 2:49 PM UTC

wickedchicken wrote: post #28

AlisdairO wrote: post #8

Earlier quoted context omitted.

Thank you. I see some variant of this argument somewhere on the web every few months, and it makes me want to bang my head on the table.

Yeah, but you have to manually do that. Maybe I'm a purist, but I hate manual features that the compiler should just 'figure out.' At best it's an unneeded annoyance, at worst you can actively slow your program down or even cause it to be incorrect . Aliasing can be tricky even to experienced programmers, and it's nicer to just have a compiler figure it out for you. It will probably do a better job anyway.

While that would be nice, it's unfortunately not the reality. The computer falls into failed optimization traps all the time. The only difference is that with a human, you can detect it with a profiler and correct the problem by reordering a few things. With automatic optimization, you can't.

Re: The "C is Efficient" Language Fallacy (2006)

#39

Post by squidfood » Mon, Jan 09, 2012, 2:53 PM UTC

jrockway wrote: post #14

nickolai wrote: post #9

Umm, yes C/C++ will not parallelize your code for you, whereas Language XYZ will. Im not sure how this is an argument against C/C++ being effective. C/C++ will not parallelize your code by design. It's was never meant to. I'd never blame my stick-shift car for not changing gears by itself - thats the first reason I didnt buy an automatic in the first place! If your matrix manupuilation code performance becomes an iss…

You're missing the point. The target demographic for this article is someone who is not a computer scientist. He's someone who doesn't have time to deal with thread libraries and low-level matrix operations. He just needs to crunch his data quickly so that he can publish his valuable research. This person reads the same blog articles that computer scientists do, and comes to the conclusion that "I should learn C++ fo…

Exactly. I'm a numerical scientist (does a lot of oceanography) who started out around 1989 in c "for speed". After 15 years of wrestling with hand rolling up, unrolling, threading, rolling for the simplest matrix multiplication, someone said "you should try modern Fortran, it's not like F77 was when you started."

my GOD what a breath of fresh air. Natural array expressions, operations slicing, sizing, etc. (talking about the core language not libraries) and incredible, incredible speed. Revolutionary, and makes me deeply regret those years I recited the "c is fast" mantra.

Mind you, the compiler that handles the optimizations is written in c. But you know - I don't need to know about that;in c, I always felt like I was half writing-the-compiler anyway. Thankfully, I'm not anymore.

Now the thing is, I tell people this and they look at me like I'm crazy ("fortran? no way!") This article... I love a little validation.

Re: The "C is Efficient" Language Fallacy (2006)

#40

Post by microtonal » Mon, Jan 09, 2012, 2:57 PM UTC

MichaelSalib wrote: post #37

microtonal wrote: post #35

Earlier quoted context omitted.

Except that there are fine high-level matrix libraries, optimization libraries, etc. for C/C++. I needed an parameter estimator for maximum entropy models that was efficient for training rankers (e.g. for parse disambiguation, fluency ranking, etc.), that also had good support for feature selection. I just used an off-the-shelf optimizer (liblbfgs), implemented calculation of the objective and gradients, plus various…

C is a very simple language. It is? Out of curiosity, did you know about all the undefined behaviors described at http://blog.llvm.org/2011/05/what-every-c-programmer-should-... and did you understand how your C compiler takes advantage of them before you wrote that statement?

It is? Out of curiosity, did you know about all the undefined behaviors described at

Yes, those are familiar and described in every decent C introduction. Of course, that doesn't mean people do not make those mistakes. Let the compiler be pedantic.

did you understand how your C compiler takes advantage of them before you wrote that statement?

At the very least, is fairly easy to understand how the compiler optimizes correct code. In say, Haskell (which I do like a lot), you often have to resort to reading ghc's Cmm output to see why something is not optimized.