Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The “C Is Efficient” Language Fallacy (2006)

scienceblogs.com

Post reply on HN
Print view View original

31–40 of 106 posts

Re: The “C Is Efficient” Language Fallacy (2006)

#31

Post by YeGoblynQueenne »

cornstalks wrote: post #15

0.8 seconds for C and 2.3 seconds for C++? That discrepancy is a huge red flag in this analysis, given that the code is so naive and simple that the program should effectively be the same between C and C++, so I would expect them to have nearly identical timings.

If I read the OP correctly the benchmark used an implementation of the Longest Common Subsequence algorithm, expected to run in O(n³) time and O(n²) space. It's a dynamic programming algorithm and so not quite trivial, but, hey, it's an algorithm. The coding is never the biggest complication with those.

As a benchmark it's probably OK, but language benchmarks in general are never very useful. Like, the op essentially makes the claim "you can't code this any faster in X language". Well, maybe you can't, but someone else can. Unless you have a way to run exactly the same code in n languages, or somehow produce exactly the same binary from n languages, then there's no real comparison, sadly.

But- we're programmers and that sort of thing is our favourite sport, innit.

Re: The “C Is Efficient” Language Fallacy (2006)

#32

Post by jarvist »

ThePhysicist wrote: post #29

Really good points! For me, the best approach to efficiency in terms of development speed and performance is to use a fast language for critical code paths and then make it accessible using a scripting language. Python and C++ work really great in this respect, as it's very easy to generate Python bindings for a C++ library using e.g. SWIG, SIP or Boost. Lua is also a good choice as an embedable scripting language an…

From your username & requirements, I'd definitely recommend looking at Julia: http://docs.julialang.org/en/release-0.4/manual/introduction...

It can be very fast by itself, and can also be written extremely high level & is very easy to form bindings to other languages, thanks to the multiple dispatch. Even small things such as having full unicode support is very nice to write maths code in a very 'pen and paper' kind of way.

Re: The “C Is Efficient” Language Fallacy (2006)

#36

Post by the_why_of_y »

dekhn wrote: post #8
dragandj wrote: post #4

While 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 be…

The numbers are indeed not independently verifiable, and it looks like they are actually from 2000, not 2006 when the article was written:

  I can’t give you the code I did the LCS tests on – as I said, it was six years ago! It’s somewhere on a backup tape, and I’d need to get permission from my employer to release it.
However the OP denies your "naive C vs. sophisticated OCaml" allegation and claims it was rather the reverse:

  At the time, I had just come off of a project where I was part of a team implementing a C++ compiler. C++ was definitely my strongest language at the time. The code in all of the languages was as carefully hand-optimized as I could make it.

  And at the time, I had *never* used OCaml; I had used its predecessor, Caml-Light for some experiments about 4 years earlier. But I was *far* from a highly skilled Caml hacker.
Quotes from this comment:

http://scienceblogs.com/goodmath/2006/11/02/the-c-is-efficie...

Re: The “C Is Efficient” Language Fallacy (2006)

#37

Post by CyberDildonics »

moyix wrote: post #34

Against this article, we have the results from the computer language shootout: https://benchmarksgame.alioth.debian.org/u64q/performance.ph... I like this because anyone can try to prove their assertion that their language is faster!

Unfortunately that site is very questionable although still might be the best resource. The person who runs it changed the interface to make it difficult to compare languages as well as it used to, and he purposely doesn't include many implementations and languages that people send him.

There is no ISPC or Julia, the C and C++ benchmarks use SIMD intrinsics specific to gcc, the benchmarks are run on core 2 processors... etc. etc.

Re: The “C Is Efficient” Language Fallacy (2006)

#38

Post by kazinator »

cornstalks wrote: post #15

0.8 seconds for C and 2.3 seconds for C++? That discrepancy is a huge red flag in this analysis, given that the code is so naive and simple that the program should effectively be the same between C and C++, so I would expect them to have nearly identical timings.

I maintain a programming language that can be built as C or C++. There is no significant difference the overall execution time of "make tests" when compiled either way, and the executable sizes are close. (No options are used to disable any C++ features; just the compiler command is switched.)

Re: The “C Is Efficient” Language Fallacy (2006)

#39

Post by rhodysurf »

gus_massa wrote: post #26
iheartmemcache wrote: post #11

Mods- put a (2006) in there please. The number-crunching ecosystem has changed drastically in 10 years. He also didn't mention what compiler he's using. Intel's ICC had a huge advantage over gcc 2.95.3 (or whatever was used in '06) especially in numerical methods. (Though, I'm not sure when Intel's MKL became semi-freeware; at which point there was a significant performance jump if one opted to use the lib appropriat…

Fortran is still used in Physics. They have a lot of libraries, and they usually have a some program of a previous paper that almost do what they want now, and they know the technology stack, so many physicist are still not planning to change. (I work with a Physics group. Sometimes I found programs with an old part that still use numbered lines for the "do". We are still trying to get rid of numbered lines ...)

I work for a company working with hydrodynamics (Potential Flow) and all of our main hydro code is written in Fortran and we don;t plan on moving away from it. Its too easy for non-software oriented engineers to write performant code in with a low barrier to entry.

Re: The “C Is Efficient” Language Fallacy (2006)

#40

Post by beezle »

gus_massa wrote: post #26
iheartmemcache wrote: post #11

Mods- put a (2006) in there please. The number-crunching ecosystem has changed drastically in 10 years. He also didn't mention what compiler he's using. Intel's ICC had a huge advantage over gcc 2.95.3 (or whatever was used in '06) especially in numerical methods. (Though, I'm not sure when Intel's MKL became semi-freeware; at which point there was a significant performance jump if one opted to use the lib appropriat…

Fortran is still used in Physics. They have a lot of libraries, and they usually have a some program of a previous paper that almost do what they want now, and they know the technology stack, so many physicist are still not planning to change. (I work with a Physics group. Sometimes I found programs with an old part that still use numbered lines for the "do". We are still trying to get rid of numbered lines ...)

Not to mention that Fortran has come a long ways from your father's (or my) Fortran IV.
Post reply on HN