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

11–20 of 106 posts

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

#11

Post by iheartmemcache »

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 appropriately in tandem with gcc.)

This guy also could have at least linked to a repo of his code... though none of that fancy github stuff was around, Sourceforge and CVSweb was around back then. Without the source we can't really accurately judge, well, much of anything. Compiler flags, JVM tunes (was it warm?), source code, data sets, or hell, even mention of compilers.

Edit: Though his point held hm, not quite 'true' categorically, but you could argue the point. Around '06, Fortran was still largely used, at least bioinformatics (sequencing, attempts at heuristic folding .. stuff), weather prediction, and was a perfect fit for linear algebra.[1] It was accessible and fast enough to be used by post-docs who didn't write software for a living, so presumably the ecosystem was founded then continued to develop within Fortran. Even if it was possible to outperform your simulations in C++ (I'm sure you could get at least fairly close), all of the work you were building off of (e.g. with your colleagues, advisors, etc) were Fortran-based.

[1] This is all hearsay from my father's / his doctoral students work from the late '90s/early '00s when I was in high-school, so I can't really offer sources on hand, but if someone really wants me to, I can fire off an email to him to gather specifics.

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

#12

Post by The_suffocated »

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…

Hmm, isn't this an infinite loop? i and j are not incremented. I'm surprised that the program can end in finite time.

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

#13

Post by danbruc »

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…

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 manually build this into the code which in turn makes it more complex.

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

#15

Post by cornstalks »

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.

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

#16

Post by shenberg »

The author is wrong about the details but right regarding the general point. Wrongness:

1. C99 has the restrict keyword to declare no aliasing.

2. there are still many places dropping down to assembly is better than what your compiler can do, mostly since C is too portable to provide access to processor flags directly (see strlen.s/asm for your platform for an example, e.g. http://lxr.free-electrons.com/source/arch/arm64/lib/strlen.S ).

3. (nitpick) Arrays are actually types distinct from pointers in C/++ (e.g. char a[5]; char * b="asdf"; a=b; will not compile, and arrays aren't interchangeable with const-value pointers like char * const either - try passing a pointer to a function accepting an array).

edit: spacing, fixed italics instead of pointers

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

#17

Post by eudox »

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…

Yeah, the thing about low-level languages like C is that they are so tied to the machine -- and CPUs are now immensely complex beasts --- that your program, to be fast, has to be written to take advantage of that machine's characteristics: using target-specific intrinsics (e.g. SSE, AVX) or designing data structures around the size of the cache line.

Whereas a higher-level language can truly abstract over of all these things, and perform target-specific optimizations where it sees them.

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

#18

Post by tokenrove »

An underlying point to this article that is still true is that C isn't inherently fast -- you have to work together with the compiler to make sure it generates what you want.

Why is this even worth pointing out? Well, in many languages communities (Common Lisp is a good example), the speed argument comes up, and it's pointed out that carefully working with the compiler (declares in all the right places and so on) makes the implementation competitive, and this is often dismissed as "too much work", ignoring the fact that even in C, there's no free lunch.

When one recognizes that good performance often requires a dialogue with the compiler, one starts to recognize that a criteria for performant language implementations is not "it's just like C" but rather "it's possible to tell the compiler to make this fast".

This makes many alternate languages viable choices for high-performance work (and eliminates some!), at least based on the current state of their implementations.

Imagine if as much work had gone into their compilers as has gone into the production C and Fortran compilers of today.

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

#19

Post by jsnell »

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.

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

#20

Post by n00b101 »

RossBencina wrote: post #7

The 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?

FORTRAN disallows pointer aliasing, which allows the compiler to perform certain instruction re-ordering optimizations. As far as I know this helps more with instruction level parallelism, as opposed to auto-vectorization. C99 introduced the restrict keyword in order to solve the pointer aliasing / instruction reordering issue.

Auto-vectorization is a bit different, it uses mathematics of integer polyhedra to perform loop transformations allowing the compiler to replace scalar operations with SIMD vector operations. The Intel C compiler and IBM XL C compiler have been quite good at this for a long time (at least on simple loops that don't really require transformations). More recently GCC implemented the "Graphite" optimizer to handle this type of auto-vectorization, and LLVM has the the "Polly" optimizer. FORTRAN automatically benefits from these optimization improvements because all these compilers have FORTRAN front-ends that translate these languages to an intermediate representation, where the optimizer don't "know" what the source language was.

I think the pointer aliasing issue still haunts C because the "restrict" keyword may not be commonly used. So FORTRAN seems even today to have a reputation of being "faster" than C for numerical codes.

Post reply on HN