Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The "C is Efficient" Language Fallacy (2006)

scienceblogs.com

Post reply on HN
Print view View original

51–60 of 133 posts

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

#51

Post by rcfox »

MichaelSalib wrote: post #37
microtonal wrote: post #35

Earlier quoted context omitted.

Except that there are fine high-level matrix libraries, optimization libraries, etc. for C/C++. I needed an parameter estimator for maximum entropy models that was efficient for training rankers (e.g. for parse disambiguation, fluency ranking, etc.), that also had good support for feature selection. I just used an off-the-shelf optimizer (liblbfgs), implemented calculation of the objective and gradients, plus various…

C is a very simple language. It is? Out of curiosity, did you know about all the undefined behaviors described at http://blog.llvm.org/2011/05/what-every-c-programmer-should-... and did you understand how your C compiler takes advantage of them before you wrote that statement?

Yes, that's what makes C simple. If all of those edge cases were covered, the language would be much more complex.

Simple != Easy to use

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

#52

Post by m_for_monkey »

squidfood wrote: post #39
jrockway wrote: post #14

Earlier quoted context omitted.

You're missing the point. The target demographic for this article is someone who is not a computer scientist. He's someone who doesn't have time to deal with thread libraries and low-level matrix operations. He just needs to crunch his data quickly so that he can publish his valuable research. This person reads the same blog articles that computer scientists do, and comes to the conclusion that "I should learn C++ fo…

Exactly. I'm a numerical scientist (does a lot of oceanography) who started out around 1989 in c "for speed". After 15 years of wrestling with hand rolling up, unrolling, threading, rolling for the simplest matrix multiplication, someone said "you should try modern Fortran, it's not like F77 was when you started." my GOD what a breath of fresh air. Natural array expressions, operations slicing, sizing, etc. (talking…

I'm interested. Which Fortran compiler would you recommend for a beginner for using on Linux?

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

#53

Post by MichaelSalib »

rcfox wrote: post #51
MichaelSalib wrote: post #37

Earlier quoted context omitted.

C is a very simple language. It is? Out of curiosity, did you know about all the undefined behaviors described at http://blog.llvm.org/2011/05/what-every-c-programmer-should-... and did you understand how your C compiler takes advantage of them before you wrote that statement?

Yes, that's what makes C simple. If all of those edge cases were covered, the language would be much more complex. Simple != Easy to use

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.

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

#54

Post by AshleysBrain »

lukesandberg wrote: post #41
MichaelSalib wrote: post #26

Putting aside his general point C efficiency, I'm curious about his specific claim that Fortran compilers outperform C specifically because aliasing conceals optimization opportunities. John Reghr points [1] to a really interesting paper from 2004 that used a special analysis tool to mark every single pointer as restrict as it safely could in the SPEC benchmark. The result was a 1% performance improvement. That sugge…

Well maybe the reason performance improved only slightly is because not a lot of effort has gone into optimizing situations involving restrict pointers because it is so rare. If it is common in fortran it would make sense that a lot of effort has gone into special optimizations for that case, the same effort would not have been spent in c compilers because it is so rare.

I'm not sure it's as rare as you make it out to be - AFAIK most compilers that support restrict declare malloc() and new to return restrict pointers, so

    int *x = malloc(100), *y = malloc(100);
followed by some loop should be able to spot that x and y are not aliased. It should also be able to propagate the restrict as pointers are passed around, at least to some extent.

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

#55

Post by cliffbean »

MichaelSalib wrote: post #26

Putting aside his general point C efficiency, I'm curious about his specific claim that Fortran compilers outperform C specifically because aliasing conceals optimization opportunities. John Reghr points [1] to a really interesting paper from 2004 that used a special analysis tool to mark every single pointer as restrict as it safely could in the SPEC benchmark. The result was a 1% performance improvement. That sugge…

Both compilers in that 2004 paper were hardware vendor compilers, which are often heavily tuned for SPEC CPU2000. Also, both were tested with cross-translation-unit optimizations enabled; inlining in key places can make many pointer aliasing problems disappear. It's likely that these compilers already know how to do whatever is needed to get good SPEC scores even without restrict.

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

#56

Post by nitrogen »

yummyfajitas wrote: post #46

The author's point is well taken, but his example leaves a lot to be desired: If you look at that loop, it can be parallelized or vectorized without any problem if and only if the array pointed to by x and the array pointed to by y are completely distinct with no overlap. But there's no way to write code in C or C++ that guarantees that. double* doMath(double** y) { double** x = allocateNew2DArray(20000, 20000); for…

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.

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

#58

Post by microtonal »

MichaelSalib wrote: post #53
rcfox wrote: post #51

Earlier quoted context omitted.

Yes, that's what makes C simple. If all of those edge cases were covered, the language would be much more complex. Simple != Easy to use

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 underlying virtual machine or compiler. The more layers you pile on top, the harder it becomes to identify bottlenecks.

Sure, you can use fast implementations of common algorithms in a high-level language. But they are often written in C or C++. So, if you want to modify or extend such algorithms (which is likely, or you could just use an off-the-shelf program), you will end up in C-land anyway.

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

#59

Post by pandaman »

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

Judging by the difference in his numbers between C and C++ he did not have a slightest clue of what he was doing. I could imagine a slight difference is possible if you use default compiler switches due to exception handling and difference aliasing rules, not 3x as he has.

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

#60

Post by jerf »

MichaelSalib wrote: post #53
rcfox wrote: post #51

Earlier quoted context omitted.

Yes, that's what makes C simple. If all of those edge cases were covered, the language would be much more complex. Simple != Easy to use

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.

It may not be what was meant, but it is the correct way in which C is simple. C is simple because, like much of UNIX (especially back in the very beginning), anywhere there was a sharp pointy bit that was difficult to handle in the compiler, it was simply relayed up to the user to handle.

I mean this descriptively, not as a criticism. It is critical to understanding C and UNIX. It is also worth pointing out that while we might all prefer "the perfect compiler that hides all problems", that "letting the pointy bits stick the user but ensuring they can handle it" still beats "a compiler that badly hides the pointy bits, still lets them stick you, and doesn't give you any way to deal with it because the assumption that you couldn't be stuck was built in too deeply".

Post reply on HN