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

11–20 of 127 posts

Re: The "C is Efficient" Language Fallacy

#11

Post by silentbicycle »

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

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

Indeed. OCaml is an interesting exception, though: it's very high-level, yet still quite fast. (The trade-off, if you can call it that, is that you have to work within its type system.) It's not necessarily as fast as (or faster than) C, but even relatively naive OCaml code is often only about 50% slower.

There's often a point of diminishing returns in spending time and effort optimizing C, and OCaml can get surprisingly close with much less work.

Re: The "C is Efficient" Language Fallacy

#12

Post by AlisdairO »

dryicerx wrote: post #6

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…

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

Re: The "C is Efficient" Language Fallacy

#14

Post by tptacek »

baguasquirrel wrote: post #8
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…

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

Re: The "C is Efficient" Language Fallacy

#15

Post by 10ren »

silentbicycle wrote: post #4
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…

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

Re: The "C is Efficient" Language Fallacy

#16

Post by silentbicycle »

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

Lua's great for this, too (and rewriting just the few hotspots is usually enough, Lua's pretty fast). They designed it to be embedded in C from day one, so it's quite easy.

Re: The "C is Efficient" Language Fallacy

#17

Post by stcredzero »

baguasquirrel wrote: post #8
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…

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…

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.

Re: The "C is Efficient" Language Fallacy

#18

Post by stcredzero »

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

Mercurial is a great example of this approach. Overall, Mercurial is comparable to Git. (Git does maintain an edge in speed, but they are still competitive.) Most of it is written in Python, though.

Re: The "C is Efficient" Language Fallacy

#19

Post by tptacek »

stcredzero wrote: post #17
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…

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.

Re: The "C is Efficient" Language Fallacy

#20

Post by 10ren »

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

Post reply on HN