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

71–80 of 133 posts

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

#71

Post by MichaelSalib »

cliffbean wrote: post #55
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.

That's a really good point. I'd love to see the same analysis done with gcc/clang/icc.

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

#72

Post by ArbitraryLimits »

jbooth wrote: post #68
yummyfajitas wrote: post #50

Earlier quoted context omitted.

Except that there are fine high-level matrix libraries, optimization libraries, etc. for C/C++. You'd be surprised how much of it is actually fortran at the bottom. Lapack and FFTpack are two of the more important examples.

True, but the reasons for that are historical, not performance-based. Lapack depends on a BLAS implementation for the primitive matrix and vector operations (the actual number crunching), and while the reference impl is in Fortran, the high-performance ATLAS implementation is written in C, and I believe Intel MKL is as well. These implementations parallelize the matrix and vector ops, leaving the single-threaded fort…

Until C changes so that the compiler can tell that a function's pointer arguments are actually arrays (a drastic change, so it will never happen), Fortran will always have a place in numeric work..

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

#73

Post by MichaelSalib »

jerf wrote: post #60
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.

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

You mean "simple" in the 'Worse is better' sense. That's fine. It means that the language designers made their lives simple at the expense of their users. But from a user's perspective, C is not simple.

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

#74

Post by archgoon »

microtonal wrote: post #62
squidfood wrote: post #43

Earlier quoted context omitted.

Yes, it is in fact so "simple" that you have to bang it on the head and shout at it to get it to actually do anything. For the audience of this article, a good test is to compare a copy of Numerical Recipes in c versus the fortran edition, where the whole purpose of the book is to present numerical code to scientists. c (and c++) have to spend ages developing up notation and workarounds for the simplest matrix to cor…

Your definition of unreadable must then differ from mine: http://eigen.tuxfamily.org/dox/QuickRefPage.html

And working code breaks when moving to new computers or upgrading the operating system, meaning you have to dive into the template library to figure out how the array alignment is working, and how Mac OS X function calls affect the stack.

Been there. Not pleasant.

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

#75

Post by jbooth »

ArbitraryLimits wrote: post #72
jbooth wrote: post #68

Earlier quoted context omitted.

True, but the reasons for that are historical, not performance-based. Lapack depends on a BLAS implementation for the primitive matrix and vector operations (the actual number crunching), and while the reference impl is in Fortran, the high-performance ATLAS implementation is written in C, and I believe Intel MKL is as well. These implementations parallelize the matrix and vector ops, leaving the single-threaded fort…

Until C changes so that the compiler can tell that a function's pointer arguments are actually arrays (a drastic change, so it will never happen), Fortran will always have a place in numeric work..

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 if you can code directly to your problem domain. But I'm pretty sure ATLAS and MKL beat the standard compiled fortran, otherwise they wouldn't exist.

In short, just because the C compiler can't parallelize your code for you doesn't mean that you can't do that yourself. It's just a lot of work.

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

#76

Post by chengl »

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. Otherwise, it's not convincing

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

#77

Post by microtonal »

archgoon wrote: post #74
microtonal wrote: post #62

Earlier quoted context omitted.

Your definition of unreadable must then differ from mine: http://eigen.tuxfamily.org/dox/QuickRefPage.html

And working code breaks when moving to new computers or upgrading the operating system, meaning you have to dive into the template library to figure out how the array alignment is working, and how Mac OS X function calls affect the stack. Been there. Not pleasant.

Well, arguably, Apple upgraded Xcode, sorry your favorite interpreter/compiler broke, is even less fun.

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

#78

Post by antirez »

C does not offer parallelization automatically, but you can pick a model, and a library, that is a good fit for turning your app into a parallel one. In this regard the following slides are interesting: http://swtch.com/~rsc/talks/threads07/ The model proposed here may not be the right one for your application, so you can design your own (including multiple processes exchanging messages for instance, or the usual threading with locks, and so forth, it's up to you).

This requires efforts but to be honest, there is currently no language that is a good fit for system programming and that is able to parallelize your code magically and automatically. Such a language would give a strong competitive advantage to programmers using it, as C did in the past over other languages, so would become mainstream soon or later, or its ideas would incarnate in some other "better C" language. If this is not happening IMHO there is something wrong in languages that currently are able to do more than C in this regard.

In programming ideas tend to take years to be accepted, but there is a very clear trend over decades: something that is really better (as in code that is faster, or simpler to write (very useful abstraction XYZ), or more easy to debug, or with higher quality libraries, or even much simpler to deploy (PHP I'm looking at you)) eventually becomes mainstream.

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

#79

Post by zvrba »

rbehrends wrote: post #25
unwind wrote: post #2

This is old (2006), and seems to base its argument around the problems with unrestricted pointers in C, that cause aliasing. As of C99, of course, C has the "restrict" keyword which allows pointers to explicitly be declared to not alias, thus enabling all these optimizations in C, too.

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…

If "undefined behavior" were an argument for keeping features out of the language, the language we would have ended up with would not be C.

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

#80

Post by ArbitraryLimits »

jbooth wrote: post #75
ArbitraryLimits wrote: post #72

Earlier quoted context omitted.

Until C changes so that the compiler can tell that a function's pointer arguments are actually arrays (a drastic change, so it will never happen), Fortran will always have a place in numeric work..

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) explicitly states, "ATLAS does not require an excellent compiler, since it uses code generation to perform many optimizations typically done by compilers."

The point is that neither C nor the C compiler used to build ATLAS's output is what makes it fast. What makes it fast is essentially a different compiler which operates upstream of the C compiler.

Post reply on HN