The "C is Efficient" Language Fallacy • Hacker News Board

Re: The "C is Efficient" Language Fallacy

#41

Post by likpok » Mon, May 04, 2009, 11:25 PM UTC

chancho wrote: post #24

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

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.

Re: The "C is Efficient" Language Fallacy

#42

Post by Aron » Mon, May 04, 2009, 11:32 PM UTC

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

Re: The "C is Efficient" Language Fallacy

#43

Post by Oxryly » Mon, May 04, 2009, 11:32 PM UTC

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…

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

Re: The "C is Efficient" Language Fallacy

#44

Post by nickpp » Mon, May 04, 2009, 11:48 PM UTC

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

Re: The "C is Efficient" Language Fallacy

#45

Post by jdvh » Mon, May 04, 2009, 11:49 PM UTC

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…

> just bumping a pointer

If only. You have to check for out-of-memory, and throw an exception if so. (This check can sometimes be optimized away, though). You also have to mark the size of the allocated block, so the garbage collector knows how many bytes to copy during the sweep phase.

Also, garbage collectors usually allocate from a shared memory pool, so every allocation also involves some mutex operations.

Allocation is bumping a pointer in theory only.

Re: The "C is Efficient" Language Fallacy

#46

Post by DanielBMarkham » Mon, May 04, 2009, 11:52 PM UTC

Oxryly wrote: post #43

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…

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

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.

Re: The "C is Efficient" Language Fallacy

#47

Post by alecco » Mon, May 04, 2009, 11:56 PM UTC

10ren wrote: post #20

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…

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

Re: The "C is Efficient" Language Fallacy

#48

Post by jrockway » Tue, May 05, 2009, 12:03 AM UTC

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…

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

Re: The "C is Efficient" Language Fallacy

#49

Post by lallysingh » Tue, May 05, 2009, 12:04 AM UTC

tptacek wrote: post #36

jjs wrote: post #31

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

You're not counting the cost of deallocation.

Not an easy thing to count globally. Your GC cost (at least in mark-sweep) is dependent on the number of objects you're not deallocating. The rest are implicitly destroyed.

Re: The "C is Efficient" Language Fallacy

#50

Post by jrockway » Tue, May 05, 2009, 12:06 AM UTC

Oxryly wrote: post #37

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, Has…

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.