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

31–40 of 127 posts

Re: The "C is Efficient" Language Fallacy

#31

Post by jjs »

tptacek wrote: post #25
lallysingh wrote: post #21

Earlier quoted context omitted.

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

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

In a semispace or generational GC, allocating memory is just bumping a pointer.

Re: The "C is Efficient" Language Fallacy

#32

Post by barrkel »

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…

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.

Re: The "C is Efficient" Language Fallacy

#33

Post by stcredzero »

noaharc wrote: post #28
tptacek wrote: post #19

Earlier quoted context omitted.

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.

I'm certainly not against C. I've just used C to write an embedded controller for doing real-time mixing of PWM control signals and laser gyroscope data for a model tilt-wing aircraft. (Which should be able to convert between horizontal and vertical modes in-flight.) I wouldn't use Smalltalk for that. (Yet. If I had 10X more CPU to burn, maybe.) Likewise, I'm not going to write my next Commodities Trading app in C.

Re: The "C is Efficient" Language Fallacy

#34

Post by zach »

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…

> This argument is as old as the hills.

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

Re: The "C is Efficient" Language Fallacy

#35

Post by wicknicks »

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.

Re: The "C is Efficient" Language Fallacy

#36

Post by tptacek »

jjs wrote: post #31
tptacek wrote: post #25

Earlier quoted context omitted.

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

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

You're not counting the cost of deallocation.

Re: The "C is Efficient" Language Fallacy

#37

Post by Oxryly »

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.

Re: The "C is Efficient" Language Fallacy

#38

Post by aplusbi »

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.

Re: The "C is Efficient" Language Fallacy

#39

Post by ezy »

chancho wrote: post #29

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

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

Post reply on HN