The "C is Efficient" Language Fallacy (2006) • Hacker News Board

Re: The "C is Efficient" Language Fallacy (2006)

#81

Post by qdog » Mon, Jan 09, 2012, 5:09 PM UTC

AngryParsley wrote: post #66

microtonal wrote: post #58

Earlier quoted context omitted.

Simple in the sense that it is a small language. There are not a lot of constructs, abstractions, etc. C lets you allocate blocks of memory, and perform operations on those blocks of memory. That's mostly it. In my experience, this very much maps to the problem domain (number crunching). If you want to do performant number crunching with most other languages, you have to not only grasp the language, but also the unde…

>Simple in the sense that it is a small language. There are not a lot of constructs, abstractions, etc. C lets you allocate blocks of memory, and perform operations on those blocks of memory. That's mostly it. You forgot "to free those blocks of memory." It's OK. We C programmers often forget this. :)

Not to pick too many nits, but I didn't use free() or malloc() for about 7 years of my career in programming C.

Embedded systems sometimes still frown upon willy-nilly memory allocation ;)

Of course, days when your build breaks and it's because someone, somewhere defined a piece of data as 8 bits, but your latest build has shifted some stuff around and suddenly two memory definitions have become one because of memory alignment...was probably more painful to track down than free() issues.

Re: The "C is Efficient" Language Fallacy (2006)

#82

Post by nitrogen » Mon, Jan 09, 2012, 5:18 PM UTC

yummyfajitas wrote: post #64

nitrogen wrote: post #56

Earlier quoted context omitted.

I think something may have been lost when you typed your code. y is a pointer to double, so can't accept two array subscripts (if it were "double * * y" it could, or you could keep it as a one-dimensional array and use something like y[(i - 2) * 20000 + j + 1]), and i and j don't appear to be incremented anywhere.

Thanks, fixed the "double * * y". The i and j not being incremented is actually an error in the original blog post - I'll leave it here for consistency.

The i and j not being incremented is actually an error in the original blog post - I'll leave it here for consistency.

Ah. In that case, I wonder how the author managed to get an infinite loop to complete in 0.8 seconds ;).

Re: The "C is Efficient" Language Fallacy (2006)

#83

Post by jbooth » Mon, Jan 09, 2012, 5:23 PM UTC

ArbitraryLimits wrote: post #80

jbooth wrote: post #75

Earlier quoted context omitted.

I'm not enough of a compiler buff to be able to say for sure, but I think for problems like BLAS or LAPACK where you have a very well specified problem and the motivation to dedicate absurd amounts of time to micro-optimization, C's got an edge there. Now, if you're writing from scratch and if the Fortran compiler is capable of the right optimizations, then yeah, it's probably more worth it to use fortran. Especially…

ATLAS is fast because its C code is generated beforehand by a more intelligent program. ATLAS is essentially the output of a compiler that has access to the information that would have been thrown away had your project been written directly in C. All the latest numeric libraries use this approach now, e.g. FFTW's backend is written in ML. The ATLAS overview paper ( http://www.cs.utsa.edu/~whaley/papers/atlas_siam.pdf…

Well ok, but someone sufficiently skilled could still hand-write code in C, using pthreads and SSE instructions, that will beat the fortran code every single time, because those constructs just aren't available in fortran and it's hard to claim that the compiler's always going to be better (as a Java guy most of the time, trust me, I'd love to believe it).

Re: The "C is Efficient" Language Fallacy (2006)

#84

Post by wvenable » Mon, Jan 09, 2012, 5:39 PM UTC

microtonal wrote: post #58

MichaelSalib wrote: post #53

Earlier quoted context omitted.

So when people say that "C is simple", you think they really mean "C is simple to implement" or maybe "C is simple to specify"? I don't think the grandparent meant either of those things and I don't think either of them are true anyway.

Simple in the sense that it is a small language. There are not a lot of constructs, abstractions, etc. C lets you allocate blocks of memory, and perform operations on those blocks of memory. That's mostly it. In my experience, this very much maps to the problem domain (number crunching). If you want to do performant number crunching with most other languages, you have to not only grasp the language, but also the unde…

> C lets you allocate blocks of memory

It doesn't even let you do that -- those things are external library calls.

Re: The "C is Efficient" Language Fallacy (2006)

#85

Post by ww520 » Mon, Jan 09, 2012, 5:39 PM UTC

gizzlon wrote: post #3

For me, the blinking and moving ads completely invalidate this site..

I didn't notice them. Was it because AdBlocker?

Re: The "C is Efficient" Language Fallacy (2006)

#86

Post by stonemetal » Mon, Jan 09, 2012, 5:44 PM UTC

jmilloy wrote: post #63

rbehrends wrote: post #25

Earlier quoted context omitted.

The problem with the C99 restrict is that its correct use is not (and cannot) be enforced by the compiler. For example, the following is legal C (in the sense that no compiler that I know of will issue as much as a warning): void f(char * restrict p, char * restrict q); char * h() { static char s[10]; return s; } void g() { f(h(), h()); } (Correctness of a program using restrict is, in general, not decidable.) The tr…

I don't know the first thing about FORTRAN. How does it enforce this?

In C restrict says in this function assume pointers don't alias. Which may or may not be true. This gives the library author a hard choice to make: limit usefulness or performance.

Fortran for the longest time(introduced in 90) didn't have pointers so there was no aliasing possible. With pointers in Fortran you have to specify what they may alias so the problem is much easier.(note: I have read about it but never actually worked in Fortran so I may be wrong.)

Re: The "C is Efficient" Language Fallacy (2006)

#87

Post by ArbitraryLimits » Mon, Jan 09, 2012, 5:49 PM UTC

jbooth wrote: post #83

ArbitraryLimits wrote: post #80

Earlier quoted context omitted.

ATLAS is fast because its C code is generated beforehand by a more intelligent program. ATLAS is essentially the output of a compiler that has access to the information that would have been thrown away had your project been written directly in C. All the latest numeric libraries use this approach now, e.g. FFTW's backend is written in ML. The ATLAS overview paper ( http://www.cs.utsa.edu/~whaley/papers/atlas_siam.pdf…

Well ok, but someone sufficiently skilled could still hand-write code in C, using pthreads and SSE instructions, that will beat the fortran code every single time, because those constructs just aren't available in fortran and it's hard to claim that the compiler's always going to be better (as a Java guy most of the time, trust me, I'd love to believe it).

Why would pthreads and SSE instructions not be available in Fortran? Pthreads are just another library which Fortran programs can link to with no problem, and a modern Fortran compiler is perfectly capable of handling inline assembler.

Re: The "C is Efficient" Language Fallacy (2006)

#88

Post by Locke1689 » Mon, Jan 09, 2012, 6:01 PM UTC

Arrays and pointers are most certainly not the same thing in C. Check yourself here:

    char x[100];
    char* y = malloc(100*sizeof(char));
    printf("Array: %ld\nPointer: %ld\n", sizeof(x), sizeof(y));

Re: The "C is Efficient" Language Fallacy (2006)

#89

Post by attractivechaos » Mon, Jan 09, 2012, 6:24 PM UTC

chengl wrote: post #76

attractivechaos wrote: post #34

The longest common substring problem (LCS) can be solved in O(n^2) time using dynamic programming, not O(n^3) as is stated by the author of that post. If the author is unable to get the basic fact right, I can hardly trust his benchmark. Also, I question the author's skill in C/C++: in my experiences, C is consistently faster than Java for such tasks and C++ is nearly as fast as C as long as we use it the right way.…

What the author mentioned is longest common SUBSEQUENCE (not substring). And it's true that LCS requires O(n^2) if only need to find ONE LCS, using dynamic programming. But if it's required to find ALL longest common subsequence, it definitely requires higher order. http://en.wikipedia.org/wiki/Longest_common_subsequence_prob... I agree that the author should post the code he used to benchmark different languages. Ot…

Can you find the proof that finding all LCS is O(n^3)? The author was talking about "the standard algorithm for computing LCS". I was assuming the standard algorithm finds one LCS only.

Re: The "C is Efficient" Language Fallacy (2006)

#90

Post by pjmlp » Mon, Jan 09, 2012, 6:32 PM UTC

jrockway wrote: post #16

exDM69 wrote: post #11

Earlier quoted context omitted.

The OP wants to point out that C hasn't got first class arrays the same way that Fortran does. The C kind of arrays get passed to and from functions using naked pointers and that makes lots of compiler optimizations more difficult because of aliasing issues while a Fortran compiler knows that two arrays cannot alias (use overlapping memory areas). By adding a "restricted" declaration to your pointer types in function…

Sort of true. In C99, you can: void f(int len){ int array[len]; printf("sizeof len: %zu\n", sizeof(array)); } Yes, I was weirded out when I saw this for the first time. But C does in fact have arrays; they're just not very good arrays.

If len is big enough your f() call will crash with a stack overflow.