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

Re: The "C is Efficient" Language Fallacy

#51

Post by makecheck » Tue, May 05, 2009, 12:27 AM UTC

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.

Re: The "C is Efficient" Language Fallacy

#52

Post by illumen » Tue, May 05, 2009, 12:33 AM UTC

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.

Re: The "C is Efficient" Language Fallacy

#53

Post by Oxryly » Tue, May 05, 2009, 12:40 AM UTC

jrockway wrote: post #50

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.

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

Re: The "C is Efficient" Language Fallacy

#54

Post by joeyo » Tue, May 05, 2009, 12:43 AM 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…

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.

Re: The "C is Efficient" Language Fallacy

#55

Post by michaelneale » Tue, May 05, 2009, 12:45 AM UTC

alecco wrote: post #47

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.

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 !

Re: The "C is Efficient" Language Fallacy

#56

Post by Allocator2008 » Tue, May 05, 2009, 1:04 AM UTC

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?

Re: The "C is Efficient" Language Fallacy

#57

Post by ramchip » Tue, May 05, 2009, 1:04 AM 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…

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.

Re: The "C is Efficient" Language Fallacy

#58

Post by lacker » Tue, May 05, 2009, 1:20 AM UTC

wicknicks wrote: post #35

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

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.

Re: The "C is Efficient" Language Fallacy

#59

Post by lacker » Tue, May 05, 2009, 1:27 AM UTC

barrkel wrote: post #32

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.

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

Re: The "C is Efficient" Language Fallacy

#60

Post by tptacek » Tue, May 05, 2009, 1:28 AM UTC

lallysingh wrote: post #49

tptacek wrote: post #36

Earlier quoted context omitted.

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.

You can't decouple the cost of malloc() from the cost of free(); if malloc has to do any more work than simply bumping a pointer (or, in the general case, grabbing a mutex and then bumping a pointer), it's a concession to free() (or to defragmentation, a side effect of free).