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

The "C is Efficient" Language Fallacy

scienceblogs.com

Post reply on HN
Print view View original

21–30 of 127 posts

Re: The "C is Efficient" Language Fallacy

#21

Post by lallysingh »

tptacek wrote: post #14
baguasquirrel wrote: post #8

Earlier quoted context omitted.

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 pe…

"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…

Small C programs start up faster than HLL programs. Small C programs run faster.

When they get bigger, they quickly bloat up to compensate for how hard C makes it to write large-scale software. Oh, and it takes a lot longer to modify those C programs, for the same reasons.

C's malloc() time is also a lot slower than GC'd languages. For them, a memory allocation isn't much more than a subtraction.

Re: The "C is Efficient" Language Fallacy

#22

Post by russell »

10ren wrote: post #15
silentbicycle wrote: post #4

Earlier quoted context omitted.

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 fi…

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

Rewrite only those pieces that are consuming a lot of time or memory, leave the rest in Python, which is particularly good at integration with C/C++. Many programs are a lot of setup, error handling, and edge cases where performance is not an issue. but LOC is.

Re: The "C is Efficient" Language Fallacy

#23

Post by stcredzero »

tptacek wrote: post #14
baguasquirrel wrote: post #8

Earlier quoted context omitted.

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 pe…

"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…

"Premature optimization" is just another way of saying "use the right tool for the job." Look at Mercurial. It's not quite as fast as Git, but it's just fine for its purpose. Most of it is written in Python, with some speed critical parts written in C. This strikes me as using the right tool for the right job at the right time. Write most of the app in something like Python. This makes it easier to write concise, understandable code that reads like pseudocode in a short time. When you have the system running correctly and get it factored in a way you find nice, then rewrite the speed-critical parts of it in C.

Having a running model of your system to profile is one of the best tools you can have for optimization.

Re: The "C is Efficient" Language Fallacy

#24

Post by chancho »

likpok wrote: post #9

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.

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.

Re: The "C is Efficient" Language Fallacy

#25

Post by tptacek »

lallysingh wrote: post #21
tptacek wrote: post #14

Earlier quoted context omitted.

"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…

Small C programs start up faster than HLL programs. Small C programs run faster. When they get bigger, they quickly bloat up to compensate for how hard C makes it to write large-scale software. Oh, and it takes a lot longer to modify those C programs, for the same reasons. C's malloc() time is also a lot slower than GC'd languages. For them, a memory allocation isn't much more than a subtraction.

First, cite sources for specific cases where a mainstream malloc() is "a lot slower" than a specific GC'd allocation in a mainstream HLL. This rings more truthy than true to me.

Second, fixing malloc slowness is among the easiest and fastest optimizations you can make in a C program (in most cases, a pool and freelist will get you 90% of the way there), and no GC'd allocator is faster than pool and arena allocation (which is usually just a couple ALU operations in both the alloc and free cases).

Third, large C programs tend to start up faster than large HLL programs. For instance, Eclipse is slower to start for me than Firefox --- and if you're thinking of Firefox as your archetypal "big bloated C++ program", remember that Firefox is by design the most complicated application most people ever run.

To make that argument work, you have to find a HLL program of comparable complexity. You didn't do that; you just imply that one exists. I'm calling you out on that.

Re: The "C is Efficient" Language Fallacy

#26

Post by tptacek »

stcredzero wrote: post #23
tptacek wrote: post #14

Earlier quoted context omitted.

"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…

"Premature optimization" is just another way of saying "use the right tool for the job." Look at Mercurial. It's not quite as fast as Git, but it's just fine for its purpose. Most of it is written in Python, with some speed critical parts written in C. This strikes me as using the right tool for the right job at the right time. Write most of the app in something like Python. This makes it easier to write concise, und…

As true as that is, it's orthogonal to the actual debate at hand. There are plenty of good reasons to pick Python, or Java, or Scala, over C/C++. But this article claims performance is one of those reasons, and then crafts a particularly leaky argument to carry that claim.

Re: The "C is Efficient" Language Fallacy

#27

Post by omouse »

tptacek wrote: post #3

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 wo…

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

Re: The "C is Efficient" Language Fallacy

#28

Post by noaharc »

tptacek wrote: post #19
stcredzero wrote: post #17

Earlier quoted context omitted.

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.

Another classic HLL vs. C argument: the anecdotal slow C program. Clearly, of these, there are many great examples. Unfortunately, it's a crappy argument, because there are also a zillion incredibly slow HLL programs.

I don't think stcredzero meant that as an argument that C is worse than HLL -- it was just a warning that, as with any tool, it can be improperly used.

Re: The "C is Efficient" Language Fallacy

#29

Post by chancho »

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
which sucks. Optimizing multidimensional array access (which characterizes most of scientific computing) is much easier for a Fortran compiler.

Re: The "C is Efficient" Language Fallacy

#30

Post by stcredzero »

tptacek wrote: post #26
stcredzero wrote: post #23

Earlier quoted context omitted.

"Premature optimization" is just another way of saying "use the right tool for the job." Look at Mercurial. It's not quite as fast as Git, but it's just fine for its purpose. Most of it is written in Python, with some speed critical parts written in C. This strikes me as using the right tool for the right job at the right time. Write most of the app in something like Python. This makes it easier to write concise, und…

As true as that is, it's orthogonal to the actual debate at hand. There are plenty of good reasons to pick Python, or Java, or Scala, over C/C++. But this article claims performance is one of those reasons, and then crafts a particularly leaky argument to carry that claim.

I read the article more like: "Writing a program in C is no guarantee of having a fast program. Here are a few examples." (Of both places where C is not the best for speed, and other languages giving good results.)

I think your idea of "the actual debate at hand" is too narrowly focused. As a reader of HN, I'm generally interested in how to get things done in a reasonably efficient manner. I find that "get it running, profile it, understand it, then optimize" is a good thing to think about when discussing performance. It cuts through a lot of delusions people have about their ability to write fast code. (Especially when they try to do it up-front.)

Post reply on HN