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

21–30 of 106 posts

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

#21

Post by cornstalks »

jsnell wrote: post #19
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.

We can't know how naive and simple the code is. As far as I can see, the timings have nothing to do with the code snippet in the blog post. Instead they are from some totally separate program, with the source code not available in any language.

That's a good point, and an even bigger red flag.

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

#22

Post by dekhn »

danbruc wrote: post #13
dekhn wrote: post #8

Earlier quoted context omitted.

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…

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. That is the point of the author, you certainly can achieve the same speed in C but you have to do extra work because the compiler is unable to do things like discovering the absence of aliasing. So you have to…

OK, so let's turn it around: are there cases where an expert user who wants to get the most out of the machine can generate faster code in OCaml than the fastest implementation an experienced C author can write?

I don't care about the average case- I care about the maximum case (because I work on performance sensitive code).

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

#23

Post by satysin »

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…

Indeed. This post is nothing more than "I did this and look at the results" but offers nothing for us to repeat his tests. Plus yeah it is a decade old, things have changed a hell of a lot in the past decade.

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

#25

Post by maxxxxx »

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 you halfways know what you are doing C++ code has at maximum a few percent overhead. I hope that C/C++ will find a better successor but this kind of naive benchmark doesn't help.

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

#26

Post by gus_massa »

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 ...)

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

#27

Post by YeGoblynQueenne »

From the empirical mini-"benchmark" in the article:

  * C: 0.8 seconds.z
  * C++: 2.3 seconds.
  * OCaml: 0.6 seconds *interpreted*, 0.3 seconds fully compiled.
  * Java: 1 minute 20 seconds.
  * Python: over 5 minutes
I have a hunch the Python version did not use numpy because numpy calls to a BLAS library in either C or Fortran to vectorise stuff and should have been close to C and C++ in performance.

Edit: numpy was available in 2006, and even earlier than that.

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

#28

Post by tux3 »

maxxxxx wrote: post #25
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 you halfways know what you are doing C++ code has at maximum a few percent overhead. I hope that C/C++ will find a better successor but this kind of naive benchmark doesn't help.

If you halfway know what you're doing, C++ code ought to be at least as fast, as you have the advantage of a reacher type system to help the compiler – no taking void pointers everywhere.

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

#29

Post by ThePhysicist »

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 and widely used e.g. in the game industry (it's faster than Python and has a tiny code footprint).

Recently I also investigated Go as my new "fast language", generating bindings for other languages such as Python is still very difficult though and many of the emerging tools (e.g. gopy) are not very well maintained our outright broken. If integration with other languages was easier I think Go would be a serious contender for this kind of scenario though.

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

#30

Post by YeGoblynQueenne »

satysin wrote: post #23
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…

Indeed. This post is nothing more than "I did this and look at the results" but offers nothing for us to repeat his tests. Plus yeah it is a decade old, things have changed a hell of a lot in the past decade.

>> This post is nothing more than "I did this and look at the results" but offers nothing for us to repeat his tests.

That's a valid gripe to have, but it should be said that most scientific papers that report simulation or algorithm results do exactly the same. Reproducing results is totally left to whomever feels like (and has the time to) dispute the claims.

Which is why you don't often see much in the way of disputation of performance claims, btw (yeah, ok, also because people take part in competitions where you get the chance to put your code where your mouth is).

Post reply on HN