The "C is Efficient" Language Fallacy

http://scienceblogs.com/goodmath/2006/11/the_c_is_efficient_language_fa.php

by silentbicycle • 17 years ago

157 124 17 years ago

madair• 17 years ago

Reminds me of The Practice Of Programming, by Kernighan and Pike, a truly excellent book. They cover some of the bum steers of C efficiency quite well there. A classic.

tptacek16• 17 years ago

This argument is as old as the hills. It's probably true in a lot of niche situations. But the fact is, most C code is faster than higher-level language code, because:

* C programmers have more freedom to arrange data in memory to exploit locality

* C data structures need less bookkeeping

* C programs manage memory manually, and so lack GC overhead

* C programs can easily swap in different allocators for different work sets

* C function calls are usually wired into the code, not indirected through (several layers of) tables.

That's to say nothing of bytecode interpretation overhead, which is probably a straw-man argument.

I buy the instruction scheduling argument for inner-loop numerical and vector scenarios, but even in performant code, that's usually less than 10% of the total, and from what I've seen, both C and HLL code tends to delegate that to machine-specific assembly libraries.

silentbicycle4• 17 years ago

While I don't have enough experience in really low-level tuning, I know that sometimes people get so focused on optimizing their current implementation that they fail to see that their overall design has trapped them in a local maxima. Problems like inappropriate algorithms are usually more obvious in higher level languages, because there's less detail obscuring them. That stuff needs to be right before getting to fine tuning. (Prototyping in another language first helps.)

C and C++ are quite fast locally, but sometimes that works against being fast overall.

tptacek16• 17 years ago

Maybe, but on the flip side, you could argue that a lot of high-level languages are trapped in hash tables, and are missing a lot of opportunities for fast tree-walking implementations.

It's tricky to really push on high-level languages because for every argument against one, there are 3 other languages that don't exhibit that problem. If there was a platonic ideal of a high-level language to argue from/with, this would be a more useful debate to have.

ramchip2• 17 years ago

DSP is one domain where performance of a tiny part of the code (say 1%) is far, far more important than everything else. If you need to apply a filter to remove high frequencies, or if you need a Fourier transform, no high-level tuning or special algorithm will cut it: you need the filter or the transform, even if it's very costly. The bottleneck is real and unavoidable.

I work in data acquisition and in this domain C/C++ is king. The raw number-crunching is essential (for our applications anyway), and any bonus that can be had from SSE operations, cache locality, loop unrolling, software pipelining, etc. can have a major impact on the overall performance. Assembly is still common on DSP processors and the like (they typically provide a special instruction set). Even in C++, we tend to use the bit-twiddling and pig disgusting optimization hacks that low-level access provides :)

Some people use higher level tools such as LabView but the performance is a huge step down. It's OK for prototyping and learning.

10ren4• 17 years ago

The standard approach I heard was to code in a very high level language (like python) to get the algorithms right, then rewrite in C for performance. Python then becomes a sort drawing board as part of the design stage, instead of "coding".

baguasquirrel• 17 years ago

I have a friend at Intel who works on their realtime raytracing efforts and he swears by C/C++. Indeed, his arguments mirrors yours and go even farther. There's all sorts of magic you can play when you've got access to the actual bits and bytes. For starters, they do things like stash data in the low-precision bits of floats and the lower three bits of pointers. I wholeheartedly concur with his opinion that in raw performance terms, C/C++ is the fastest.

The problem with his argument and yours is that C is NOT faster for The Rest of Us because it it amounts to premature optimization just by virtue of using it. And because it takes so much effort to get C code to just work, the WHOLE program ends up being slower than the corresponding code in Haskell, OCaml, or perhaps even CLisp. Having worked my last job in a company where the programmers preferred C to C++ and C++ to Python, it startles me how utterly slow our system was. And ditto for the previous job.

At my first place, we had a streaming video server that had blindingly fast compression routines, but it was all held up by a UI loop that harked from the prototype days. Thus the argument that C/C++ is/are the best languages for fast code is moot. It is only the fastest if you've all the time in the world to write it.

tptacek16• 17 years ago

"Premature optimization" is another hoary old argument that gets dragged into this debate every time it comes up. But I don't think it's valid.

C programs start up faster than HLL programs. They run faster. They consume less memory. They tend to be more responsive.

From "looking up an object by its string name" to "splitting a string on the comma character" to "running the following functions on a 10hz timer", simple operations that all programs do have less overhead in C than they do in many high level languages, because the C program isn't creating and disposing of hundreds of little objects every time it does one of those things.

Hey --- I write most of my code in Ruby. I'm not saying you should use C. But you shouldn't make up bad reasons not to use it when there are so many good reasons to cite.

stcredzero8• 17 years ago

Right. C is a power tool. You can use it to create something blindingly fast. You can also use it to create something dog slow. I've seen Smalltalk programs outperform C programs. I know of an instance where a coworker benchmarked a C implementation of a block cipher vs. a Smalltalk implementation, and the Smalltalk ran 3% faster. Why? Naive manual memory management in the C implementation.

omouse• 17 years ago

What about Forth? As far as I know it can do all the stuff that C can do plus some more nifty things.

jongraehl• 17 years ago

Forth is ridiculously simple to implement. But there's no reason to use it, beyond that. It's less expressive than C but not faster.

barrkel2• 17 years ago

For me, this argument in favour of C is really missing the point. In the long run, maintenance costs dominate, and unsafe languages like C lead to programs that take more and more programmer time to maintain, and it becomes harder and harder to see the high-level structure and optimize that through refactoring, rather than the low-level bottlenecks that show up in profilers.

lacker2• 17 years ago

Maintenance costs do not always dominate. If you are working on code that will run on many thousands of machines, then hardware and running-the-cluster costs dominate. Performance improvements that are small in terms of % can still be worth many programmer-months of effort, and it becomes optimal to use C or C++.

zach• 17 years ago

> This argument is as old as the hills.

Of course. It's the "disproving a generalization from its exceptions" argument fallacy.

Oxryly3• 17 years ago

> C programmers have more freedom to arrange data in memory to exploit locality

I think just about everyone here is underestimating the impact of this one "feature". Most optimization approaches are grounded in 1970s computer hardware, where CPU speed and memory speed were two aspects of the approach. That's not the case anymore... memory access times absolutely dominate on modern hardware. Just lookup the number of instruction cycles a cache miss takes for your favorite system. Its appalling.

C and C++ have been able to stay ahead of the curve because they allow strict control over memory layout. Ocaml is often brought up as a competitor, but storing a floating point value in ocaml requires a boxed pointer! Nevermind trying to make an aggregate structure that includes floats and other types bundled together... everything will get boxed and the cache never stands a chance.

C and C++ are the only fully current languages that let you bundle your data exactly as you need it in as small space and in appropriately sized chunks such that memory access doesn't grind your program down. Of course you can fail to take advantage of this ability and write slow code in C or C++; in which case you'll match the benchmarks for your other favorite languages and maybe make a blog post about it. That'd be missing the point though...

DanielBMarkham• 17 years ago

I agree.

People don't realize what a power tool C/C++ is because they haven't had it out for a spin at that level. If you've done serious API work, and wondered why you're busy byte-packing, it's because there's some highly optimized code somewhere you're feeding. You can allocate a big honking chunk of memory and create your own world in there. Boxing, for all its goodness, is a performance killer.

jrockway3• 17 years ago

C programs manage memory manually, and so lack GC overhead

At this point, GC is often faster than manual allocation. (Due to being able to allocate or deallocate a bunch of things at once, rather than having to allocate/free memory whenever the programmer says to.)

tptacek16• 17 years ago

You too are committing the fallacy of assuming that "managing memory manually" means using malloc() and free(). Fast programs don't use malloc() directly. Hell, even apr programs have standardized on this optimization.

Many GC schemes are probably faster than malloc. But it's a much less credible argument to say that you have a GC that is faster than a custom allocator tuned to a workset. You probably don't.

vegai3• 17 years ago

A competent C programmer can clearly make a good, performant program in 10klines. A genius programmer, maybe 100klines.

There's something beyond those figures, though. And it gets worse when a team is involved.

The higher the level of the language rises, the less it allows making bad programs, however big the program is.

neilc• 17 years ago

> The higher the level of the language rises, the less it allows making bad programs

I think it's more complicated than that. Ruby is higher level than Java, but I would argue that Java makes it harder to write bad programs, especially in a team setting.

AlisdairO3• 17 years ago

Much as I take his overall point - that a close to the metal language is not always best for performance - the author would be well advised to take a look at the C99 restrict keyword.

setjmp• 17 years ago

Just looked it up... looks like you're right. The whole blog post is nonsense.

habibur• 17 years ago

Just asking, does currently available compilers support restrict? (or C99 standards)?

I use msvc mostly and gcc sometimes.

dryicerx• 17 years ago

I disagree with some of the Authors points.

The language is a tool, the efficiency of it really depends on how the programmer who designs and implements a program. You can have a horrible coder write something in C that would be very slow and inefficient, and given the same problem to good programmer and you can arrive at a faster and more efficient result using a bash script.

The reason why lot of people (including my self) believe that C/C++ is a high performance language is not because it fast for all applications, but gives the programmer more control instead of leaving all the fine details to the compiler to second guess. (@tptacek's reasons are perfect for this).

AlisdairO3• 17 years ago

...except that in this case, when you take full control of the memory management, you slow things down. The problem with using pointers (without using the restrict keyword) is that it can seriously impede out of order processing on modern CPUs. Now, the author has missed the existence of the restrict keyword in C99, but in the absence of that his point is good.

likpok2• 17 years ago

One issue that I see is that they only (seem) to compare with gcc, which is not particularly good. It would be better to compare against something like icc, which has better register coloring, SIMD support, etc.

This might redeem C a little.

However, the real reason C will not go away any time soon is that there is no replacement for low-level software yet. Nothing eles has quite the same minimal dependencies.

chancho3• 17 years ago

GCC C vs Intel Fortran : http://shootout.alioth.debian.org/u64/benchmark.php?test=all...

Intel C vs Intel Fortran : http://shootout.alioth.debian.org/gp4/benchmark.php?test=all...

(I'm not even going to link to the GCC Fortran benchmarks. They're embarrassing.)

C is no slower than Fortran on any of those benchmarks, and on some it cleans Fortran's clock. The aliasing issue is the only thing Fortran has going in its favor, but clearly its not ubiquitous. The n-body benchmark, for instance, is fairly typical numerical code. You might even think, since it's simultaneously reading and writing through multiple pointers of the same type, that aliasing is an issue, but its not. And in the rare case that it becomes an issue, there's compiler hints (e.g. C99 restrict) for that.

Picking Fortran over C solely because of aliasing worries is premature optimization of the worst kind.

likpok2• 17 years ago

This matches with my experiences with ICC doing kernel development. It would vectorize loops and break out the SIMD instructions where gcc would not.

It was quite strange the first time looking through the objdump seeing things like punpwlkd and xmm.

And then discovering what -fast would do to things (it makes icc look at your whole program to optimize, so it does things like ignore CDECL and uses whatever registers it can.

ramoq• 17 years ago

I remember reading this article years ago :)

10ren4• 17 years ago

Java: 1 minute 20 seconds.

About a year later, testing a new JIT for Java, the Java time was down to 0.7 seconds

I've been surprised at the speed of Java recently. I wonder how much improvement is left in dynamic compilation.

The HP project Dynamo was an experimental JIT compiler where the bytecode format and the machine code format were of the same type; the system turned HPA-8000 machine code into HPA-8000 machine code. Counterintuitively, this resulted in speed ups, in some cases of 30% since doing this permitted optimisations at the machine code level. For example inlining code for better cache usage and optimizations of calls to dynamic libraries and many other run-time optimizations which conventional compilers are not able to attempt. http://en.wikipedia.org/wiki/Just-in-time_compilation

alecco• 17 years ago

Time-space trade-off. Meaning Java uses a lot of memory for almost anything. Speed isn't everything.

michaelneale• 17 years ago

Sometimes memory can cost speed as well.

I find with java essentially you are amortising gains which are payed back with GC at a later date (in many cases I guess it is worth it).

Its not one size fits all !

chancho3• 17 years ago

Fortran's (alleged) dominance in scientific is probably attributable to tradition (they still teach it to undergrads in non-CS departments) but the native multidimensional arrays have a much bigger impact than aliasing. In Fortran you just index your array like A(i,j,k) and the compiler will compute (and optimize) the addressing for you. In C, a typical (non-computer) scientist who doesn't really focus on mundane shit like this will end up writing something like

    for ( int i=0; i<ni; ++i )
    for ( int j=0; j<nj; ++j )
    for ( int k=0; k<nk; ++k ) {
       a[ k*ni*nj + j*ni + i ] = ...
    }

which sucks. Optimizing multidimensional array access (which characterizes most of scientific computing) is much easier for a Fortran compiler.

ezy• 17 years ago

This is what people mean when they say pointers may be able to look like arrays, but arrays are not necessarily pointers.

Consider, "float a[X][Y][Z]" and "a[i][j][k]".

Aron• 17 years ago

This looks like a lot of calcs for the inner loop but is quite easily optimized. The compiler knows that (j * ni + i) is constant in the k loop and that ni * nj is constant. Check the assembly output. But it is probably better to reorder the loops and traverse linearly through memory so that each cache line brought down is fully consumed in order.

scott_s2• 17 years ago

The point of that code example is not the calculations, but accessing memory in a cache-friendly way.

joeyo• 17 years ago

AFAIK, if you want to work with BLAS, LAPACK and friends you have to structure your matrices like this (as a big block of data) rather than pointers to pointers to pointers (ie a[i][j][k]). So even if there is some inefficiency in filling the data structure, presumably the actual matrix multiply or SVD or what-have-you, is actually quite fast.

ramchip2• 17 years ago

I don't know how widespread this is, but my uni teaches Python to the physics (and AFAIK most science) undergrads. Some also do C, but no Fortran.

wicknicks• 17 years ago

The arguments about language efficiency on a single processor machine are probably outdated today. Most machines have multiple cores. We need good tools which can exploit this CPU architecture. Languages like C/C++ place a large amount of responsibility on the shoulders of a programmer. Effectively, you are writing two programs - one for the task at hand, and the other is memory allocation for it. Control does not always give speedup, also it is not always a boon. It implies managing the different resources on your own. In a large scale application, this is not a great idea. GC is a good alternative over Malloc and Free'ing when the size of the application gets huge.

Also, the scalability of a single system is limited. If you really need extra speed, I think going parallel is the key. Most numerical methods are parallelizable. And C/C++ were not created keeping this mind. It can be a programmer's nightmare to debug multiple threads with memory leaks. Languages like Java do make this task easier using programming paradigms like Map/Reduce.

lacker2• 17 years ago

It doesn't make sense to use mapreduce as an example of Java making parallelism easier, given that the original Google MapReduce is a C++ framework.

e4m• 17 years ago

Boost has portable threads for C++ right now... in fact, the next C++ release (due out this year) will include threads by default. http://en.wikipedia.org/wiki/C%2B%2B0x#Threading_facilities

Oxryly3• 17 years ago

For the given example code the answer is to use the underlying SIMD types and intrinsic instructions. If you're on Intel or PowerPC then the SSE or Altivec registers and instructions are available. Use them and you'll beat any compiler optimization every time. And, most importantly, the chances that up-to-date SIMD types and intrinsics will be available in any language but C/C++ is vanishingly small. Java, Ocaml, Haskell... you name it, you can't properly use SIMD (AFAIK... please let me know if there are exceptions).

And if you're application doesn't fit the native SIMD properly, there's no chance the compiler can really do anything meaningful with it anyway.

jrockway3• 17 years ago

Some quick googling suggests you are wrong:

http://www.cas.mcmaster.ca/~kahl/Publications/TR/Anand-Kahl-...

http://wwwlasmea.univ-bpclermont.fr/Personnel/Jocelyn.Serot/...

http://tirania.org/blog/archive/2008/Nov-03.html

etc.

Oxryly3• 17 years ago

I would suggest taking a closer look at those links. They bring up another point in that you'll only find current, usable, robust support for SIMD in C++:

The first link is just a paper; the second is a 1.0 release that is seven years old, it only supports SSE, and it's all in French; the third is only for Mono, it only supports SSE and its SSE support is old and incomplete.

On the other hand, if you try to use SIMD types and intrinsics in C++ you'll find current and comprehensive support from the major compilers on all SIMD platforms.

(I'd love to use a current and comprehensive version of Haskell SIMD, but its just not ready for prime time.)

aplusbi• 17 years ago

I think a large part of the "C is Efficient" fallacy/truth is that C is more predictable with its assembly output than HLLs. Since ultimately all programs are converted to machine instructions at some point, you will always be able to write machine instructions that are at least as efficient.

The test lies in the ability of the programmer to do so.

jgrant27• 17 years ago

http://news.ycombinator.com/item?id=591897

nickpp• 17 years ago

Read the comments: turns out the author was ignorant of C++ templates (including Blitz++ scientific computing library) and he was lumping C and C++ together in his "benchmarks".

It always annoys me when clueless people judge a language they don't even understand.

Repeat after me: there is no such thing as C/C++.

sundarurfriend• 17 years ago

> turns out the author was ignorant of C++ templates

I believe you actually meant 'ignorant of C++ template metaprogramming techniques'. The author seems well aware of C++ templates and even says:

>> the thing I coded immediately before the Stellation experiments was a very hairy template analysis for a C++ compiler

>he was lumping C and C++ together in his "benchmarks".

I couldn't see where, could you point out which comment leads to that inference?

makecheck2• 17 years ago

Always remember that the total time between you having a problem, and you achieving results, includes the coding (and recoding) time, and the run time. There's a tendency for people to ignore "slow" languages because they focus only on the runtime.

I am well aware that there are good reasons to optimize things in languages like C (and I use them), but consider...

If I take several extra weeks to code, debug and test a C solution, and I could have had a script done much sooner, then my results were not faster overall. Why? Well, the script could be slow as dirt, but if it has a few extra weeks to churn through data and produce results, it may be done before the C program is even ready.

It's also important to remember that not all bugs are in software. Suppose I was looking at an entire problem in the wrong way, and this wasn't apparent until I started seeing results? In that case, my earlier start with a "slow" program meant that this mistake was found much sooner, so the script can be thrown out and redone, producing correct results with not much of a time penalty.

boryas2• 17 years ago

Also, thought I would mention the fact that if you take a day to write a slow program that takes a week to run, that's cheaper than spending a week writing a fast program that finishes in a day. After all, your time is much more expensive than the computer's!

fauigerzigerk2• 17 years ago

You're both making a pretty odd assumption here, which is that a program typically runs exactly once and that I am the only user of my own program.

Users' time is also much more expensive than the computer's. That's why we write software in the first place.

illumen• 17 years ago

C works in CUDA and OpenCL - which for scientific programming is the fastest thing there is.

The GPU is used with C.

C isn't faster than hand coded assembler on cpus... but is pretty damn quick.

There are specialist compilers for C, like vector C etc.

anyway... whatever. back to typing text into a file now.

malkia• 17 years ago

CUDA and OpenCL have C syntax, but they are not C.

Allocator2008• 17 years ago

Regarding the discussion of "real" arrays in Fortran vs. "pointer arrays" in c, it seems in the real world often we need resizable arrays, which means the only way to do that is to have pointer arrays. A Fortran array cannot be resized. What if I want to read in a tab delimted file that has ints, and read that into a 2-D matrix, where the matrix rows correspond to the file rows, and the matrix columns correspond to the tab delimited columns in the file. And I have say no idea how big the file is. So the only way I can do this is to have a resizable array. I can "guess" that say my rows/columns won't be more than some arbitrarily large number, but then I likely end up wasting a lot of space. So out of curiousity how would I even do that with "real arrays"? Seems like if I ever need to resize an array, even in just as simple an example as reading in a file, then I need a pointer array, since "real" (fortran-like) arrays will not resize. Am I missing something here?

kmavm• 17 years ago

I worked on VMware's virtual machine monitor from 2000 until June. Overcoming customers' performance fears was a major impediment in the early years. Every fraction of a percent we gave up relative to native ruled out whole classes of applications. Nothing other than C would have been conceivable. Even C++ would have been wildly inappropriate, as it is for most kernels, because so much invisible code can hide behind a close-brace.

The mapping from source to machine representation in C is relatively trivial, which is the source of all C's ups and downs. If you ever plan to count microseconds, cache misses, TLB misses, mispredicted branches, etc., you had better start with a toolchain whose machine-level output is grokable from the source.

bradgessler• 17 years ago

Where is the "Assembly is Efficient" Language Fallacy article?

c00p3r• 17 years ago

In most cases manually cooked food is much cheaper and more healthy than purchased one, if you can cook. The same is correct for C/C++ programming in terms of execution speed and resource usage if you have knowledge and experience.

btw, JVM is mere a c++ code.

oomkiller• 17 years ago

This is an interesting article, but I believe that the benchmarks should be updated since a ton of progress has been made in compilers and how they handle aliasing.

wlievens3• 17 years ago

He's absolutely right about pointer aliasing. I work on a DSP compiler for architectures strongly geared towards instruction-level parallelism, and when the compiler occurs pointers that may alias (but probably won't, but we can't tell because of the language's liberal use of pointers), many optimizations have to be a lot more conservative.

ilitirit• 17 years ago

C is one of the fastest languages and most space-efficient languages out of the box. Other languages get their speed by resource trading (memory, space, time). You could arguably gain these sort of speed ups in C if you invested enough time in writing a VM or JIT-ing/dynamic compiler to host your C program.

jamii• 17 years ago

The debate seems to be between trusting your compiler to generate good code or writing close-to-metal code yourself.

There might be a third option though - code generation in a HLL. Coconut is a nice example of this:

http://www.youtube.com/watch?gl=GB&hl=en-GB&v=yHd0u6...

Instead the compiler being a black box, Coconut is structured as a set of libraries for code generation, analysis and optimisation. They report outperforming c SIMD by up to 4x on the cell architecture.

ddg• 17 years ago

"In C and C++, there's no such thing as an array - there's just pointers, which you can subscript and a shorthand for pointer arithmetic and indirection(x[n] in C/C++ is the same thing as (x+n).)"

Please remember that "char x[N];" and "char x = malloc(N);" are NOT the same. (Not sure if this is news to anyone, but when I was learning C reading that would have made me think otherwise).

The "C is Efficient" Language Fallacy

Related Stories