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

61–70 of 133 posts

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

#61

Post by AlisdairO »

wickedchicken wrote: post #28
AlisdairO wrote: post #8

Earlier quoted context omitted.

Thank you. I see some variant of this argument somewhere on the web every few months, and it makes me want to bang my head on the table.

Yeah, but you have to manually do that. Maybe I'm a purist, but I hate manual features that the compiler should just 'figure out.' At best it's an unneeded annoyance, at worst you can actively slow your program down or even cause it to be incorrect . Aliasing can be tricky even to experienced programmers, and it's nicer to just have a compiler figure it out for you. It will probably do a better job anyway.

I really don't mind seeing people say "it's easier to do this and make it run fast in another language" - that's a completely fair argument. It just really annoys me when I see "C can't do this", when it can (and has been able to do so for a long time). It makes the author appear completely ignorant.

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

#62

Post by microtonal »

squidfood wrote: post #43
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…

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

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

#63

Post by jmilloy »

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…

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

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

#64

Post by yummyfajitas »

nitrogen wrote: post #56
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.

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.

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

#65

Post by hyperbovine »

nickolai wrote: post #9

Umm, yes C/C++ will not parallelize your code for you, whereas Language XYZ will. Im not sure how this is an argument against C/C++ being effective. C/C++ will not parallelize your code by design. It's was never meant to. I'd never blame my stick-shift car for not changing gears by itself - thats the first reason I didnt buy an automatic in the first place! If your matrix manupuilation code performance becomes an iss…

For the record, you should never be paying someone to tinker with and/or parallelize low-level matrix routines. The numerical linear algebra folks spend their entire careers thinking about this stuff and writing (FOSS) software to wring every last bit of performance out of the hardware. There are specialized suites for multicore, distributed and even GPU setups.

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

#66

Post by AngryParsley »

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…

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

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

#67

Post by squidfood »

m_for_monkey wrote: post #52
squidfood wrote: post #39

Earlier quoted context omitted.

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?

gfortran is just fine! Intel fortran is a step up on various optimizations (especially parallel architectures) but gfortran is a good baseline.

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

#68

Post by jbooth »

yummyfajitas wrote: post #50
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…

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 fortran code in more of a "controller" role.

There's also work being done to parallelize the LAPACK operations at a higher level than delegating to parallel BLAS, it's shown promise but isn't done yet, see the PLASMA package released by some oak ridge national labs people.

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

#69

Post by rbehrends »

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?

This is independent of what FORTRAN does. The problem with the "restrict" keyword in C99 is that introducing it can make otherwise correct code incorrect and the compiler can't tell you.

As to program analysis, programming languages without pointer arithmetic have it a lot easier than languages with. The pair (array, index) holds more information than the address of array[index]. For example, it is trival to perform array bound checks if you have the former information, but very hard if you deal with arbitrary pointers. Pointer arithmetic loses information.

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

#70

Post by ArbitraryLimits »

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

You're confusing simplicity of interface and simplicity of implementation.
Post reply on HN