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

11–20 of 133 posts

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

#11

Post by exDM69 »

emillon wrote: post #4

> In C and C++, there's no such thing as an array Yes there is. `int a[10]` allocates 10 consecutive `int`s on the stack, and it's the only language construct to express that (with `alloca` but it's a builtin function).

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 signatures, the compiler assumes no aliasing occurs and goes on with the optimizations. It's the coders' responsibility to make sure no aliasing happens, but if it does, all hell can break loose.

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

#12

Post by exDM69 »

jensnockert wrote: post #10

While a lot of Scientific computing is done in FORTRAN, much of the lower-level `plumbing' is written in assembly, C or C++. C isn't an efficient language, C is just thin layer on top of assembly. You can write shit code in C, I know that from experience, but you can also write really fast code in C.

> C isn't an efficient language, C is just thin layer on top of assembly.

This is a pretty common fallacy. These days a C compiler does so much magic that calling it sugared assembly doesn't describe it accurately.

With a 1970's single pass compiler your argument may have been more true.

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

#13

Post by jmaygarden »

cks wrote: post #7

I was actually under the impression that Fortran was used simply because the experts (in this case in fluid dynamics) was familiar with Fortran. It was the language they learned and used while back at the university. At least this is the impression I got from working in the field. I never heard of anyone suggesting we should use Fortfran for performance reasons, instead there was an ongoing movement to evolve the cod…

Matrix operations can be faster in FORTRAN than C because of differences in the way arrays are defined/implemented in each language.

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

#14

Post by jrockway »

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…

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++ for my number crunching". That's simply not the case; you can use C++ to get good performance, but the amount of knowledge you need to acquire to do so is an entire field. You aren't going to be the world's best human genome researcher and C++ programmer; the time spent learning C++ could have been used to do research.

The idea is: if you use a tool that lets you describe your problem at a high level and let the computer worry about how to do the calculation efficiently, you'll beat your hand-rolled C++ every time. And, there is now the possibility of hiring a "Real Programmer" to hack your math library (Octave, Mathematica, Python + numpy, whatever), allowing you to delegate work. If every calculation was a brand new C++ program, you'd only be able to improve your application's performance by hacking on your application. Separating the problem description and the solution description allows the solution-finding code to be optimized without knowledge of the specific problem.

I think this approach scales to the work that practicing programmers, too. We don't see it a lot because writing tools is time consuming and we all have deadlines; so we pic k the "worse is better" solution and hard-code our applications in what amounts to glorified machine code.

Just because a practice is common doesn't mean it's a good idea.

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

#15

Post by jrockway »

exDM69 wrote: post #12
jensnockert wrote: post #10

While a lot of Scientific computing is done in FORTRAN, much of the lower-level `plumbing' is written in assembly, C or C++. C isn't an efficient language, C is just thin layer on top of assembly. You can write shit code in C, I know that from experience, but you can also write really fast code in C.

> C isn't an efficient language, C is just thin layer on top of assembly. This is a pretty common fallacy. These days a C compiler does so much magic that calling it sugared assembly doesn't describe it accurately. With a 1970's single pass compiler your argument may have been more true.

Yes, but it would be just as easy to write an "assembly compiler" that did the same optimizations on your program text. C provides a layer above the machine that acts as we imagine a machine to work; the compiler adjusts our expectation to reality.

In the end, C has branching and memory access, and that's basically what our computers have too. The rest is details.

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

#16

Post by jrockway »

exDM69 wrote: post #11
emillon wrote: post #4

> In C and C++, there's no such thing as an array Yes there is. `int a[10]` allocates 10 consecutive `int`s on the stack, and it's the only language construct to express that (with `alloca` but it's a builtin function).

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.

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

#17

Post by feralchimp »

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…

There is a very small set of humans who should be implementing their own performance-intensive numerical computing routines, in any language.

Should I happen to wander into a problem space that needs this stuff, my choice will be how many minutes to spend Googling for a decent free library, or whether to license a commercial one.

On the shoulders of giants...

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

#18

Post by zvrba »

C and C++ are efficient for general-purpose programming, if you know how to use them. C is here to stay because it is lingua franca of the computing world: OS APIs are defined in terms of C functions, and I know of no libraries in wide-spread use that do not offer a C or C++ interface.

People otherwise rightfully challenge his conclusions.

There's a funny comment there about matlab: "MATLAB struck me as being the wrong tool for every problem."

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

#19

Post by adgar »

jrockway wrote: post #15
exDM69 wrote: post #12

Earlier quoted context omitted.

> C isn't an efficient language, C is just thin layer on top of assembly. This is a pretty common fallacy. These days a C compiler does so much magic that calling it sugared assembly doesn't describe it accurately. With a 1970's single pass compiler your argument may have been more true.

Yes, but it would be just as easy to write an "assembly compiler" that did the same optimizations on your program text. C provides a layer above the machine that acts as we imagine a machine to work; the compiler adjusts our expectation to reality. In the end, C has branching and memory access, and that's basically what our computers have too. The rest is details.

> Yes, but it would be just as easy to write an "assembly compiler" that did the same optimizations on your program text.

While there are ways to optimize machine code without extra debug information, no, what you've said is not true. It is not nearly as easy to optimize machine code as it is to optimize C.

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

#20

Post by m_for_monkey »

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.

At first I didn't include the date in the title, because I don't think it matters, the author's position seems even stronger now with many popular alternative languages, fast VMs and effective JIT compilers. Anyway, C99 was, of course, already 6-7 years old in 2006.
Post reply on HN