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

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

#101

Post by rcfox » Mon, Jan 09, 2012, 9:28 PM UTC

KingMob wrote: post #99

wickedchicken wrote: post #32

Earlier quoted context omitted.

If you're an engineer (like an engineer engineer, not a software engineer) 90% of the time matlab has some module built-in or for sale that simply solves the problem you have. For example: http://www.mathworks.de/products/dsp-system/demos.html?file=... The code to construct an LMS filter ( http://en.wikipedia.org/wiki/Least_mean_squares_filter#LMS_a... ) is effectively one line: h = adaptfilt.filtxlms(L,muW,1,Hhat);

You've hit the nail on the head. This is exactly why Matlab is so pervasive in science. Not because it's actually good, but because it has so many handy libraries. The Mathworks is the Microsoft of science. I had to use Matlab for seven years in neuroscience, and it's a terrible language for everything other than matrix math, data plotting, and (if you cough up for the Parallel Computing Toolbox) easy parallelization…

Somewhat off-topic: Have you heard of the Neural Engineering Framework? http://ctn.uwaterloo.ca/~cnrglab/?q=node/10 It's got a Python (well, Jython) scripting interface and can also interact with Matlab.

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

#102

Post by loup-vaillant » Mon, Jan 09, 2012, 9:37 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…

> In my experience, this very much maps to the problem domain (number crunching).

I find that… odd. Surely we all know here that number crunching wasn't C's domain to begin with. It was writing an OS (UNIX) on 2 slightly different machines.

But even more disturbing, are you seriously suggesting that being able to manage the freaking memory makes you closer to number crunching? Sorry for the emphasis, but I am astonished. Manual memory management (and unrestricted pointers for that matter) are about the hardware. They are about manual tweaking of implementations. They are definitely not about number crunching.

And even if they were, I take one goal of number crunching is to milk every single cycle out of your CPU farm. As far as I know, C loses that match to Fortran.

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

This is already the case with C. It has been a few years (decades?) since C code and assembly no longer match neatly at all. GCC optimized assembly code is such a mess that I see it as hermetic magic. Heck, even the performance model of modern CPU is half magic to me.

Now you are correct. I'm just saying that it applies to C as well.

But there is hope. The Viewpoint Research Institute, with their STEPS project, managed to write a complete compilation suite in about two thousands lines of code. It's not optimized for runtime speed, but it does suggest that it might eventually be manageable. Here is their last report: http://www.vpri.org/pdf/tr2011004_steps11.pdf

> Sure, you can use fast implementations of common algorithms in a high-level language. But they are often written in C or C++.

Of course. But the the OP did quite clearly talk about implementing those algorithms completely in those high-level languages. Either he was being dishonest, or your argument doesn't apply.

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

#103

Post by scott_s » Mon, Jan 09, 2012, 9:46 PM UTC

haberman wrote: post #100

As someone who doesn't know Fortran, how does Fortran solve the aliasing problem? Even if pointers and arrays are different, how can you ensure two arrays don't alias each other? The only way I can think of to do this is to always copy arrays when they are passed to functions, but this seems expensive. Otherwise I don't see how you can avoid this pseudocode: void f(array1, array2) { /* somehow guaranteed not to alias…

I thought about it, and I realized I didn't know. This is the best discussion I found: http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Aliasing-Assumed...

Short answer: they don't. What you wrote is an undefined behavior, just like dereferencing a null pointer in C. If the compiler can't tell statically, then it just assumes they're not aliased.

I'm basing this conclusion mainly on this statement from that piece on aliasing: Essentially, compilers are promised (by the standard and, therefore, by programmers who write code they claim to be standard-conforming) that if they cannot detect aliasing via static analysis of a single program unit's EQUIVALENCE and COMMON statements, no such aliasing exists. In such cases, compilers are free to assume that an assignment to one variable will not change the value of another variable, allowing it to avoid generating code to re-read the value of the other variable, to re-schedule reads and writes, and so on, to produce a faster executable

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

#104

Post by KingMob » Mon, Jan 09, 2012, 10:29 PM UTC

rcfox wrote: post #101

KingMob wrote: post #99

Earlier quoted context omitted.

You've hit the nail on the head. This is exactly why Matlab is so pervasive in science. Not because it's actually good, but because it has so many handy libraries. The Mathworks is the Microsoft of science. I had to use Matlab for seven years in neuroscience, and it's a terrible language for everything other than matrix math, data plotting, and (if you cough up for the Parallel Computing Toolbox) easy parallelization…

Somewhat off-topic: Have you heard of the Neural Engineering Framework? http://ctn.uwaterloo.ca/~cnrglab/?q=node/10 It's got a Python (well, Jython) scripting interface and can also interact with Matlab.

No, I hadn't heard of it, but I was operating slightly higher, in cognitive neuroscience, and doing a lot of fMRI and intracranial EEG work. For those domains, the biggest packages are SPM and Fieldtrip, both of which run on Matlab.

I do, however, hope that Python will push out Matlab one day.

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

#105

Post by repsilat » Mon, Jan 09, 2012, 10:46 PM UTC

pjmlp wrote: post #90

jrockway wrote: post #16

Earlier quoted context omitted.

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.

I don't understand why stacks are still so small. On nice operating systems memory is only needed when it's touched, not when it's asked for, so making the stack large doesn't cost anything unless you need a large stack. On 64-bit systems you could make the stack a billion gigabytes and still have 95% of your process' virtual address space available for the heap.

On Windows the stack is one megabyte by default. We live in the future and we're still afraid of recursion without tail-call optimisation and arrays on the stack. Ridiculous.

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

#106

Post by haberman » Mon, Jan 09, 2012, 10:58 PM UTC

scott_s wrote: post #103

haberman wrote: post #100

As someone who doesn't know Fortran, how does Fortran solve the aliasing problem? Even if pointers and arrays are different, how can you ensure two arrays don't alias each other? The only way I can think of to do this is to always copy arrays when they are passed to functions, but this seems expensive. Otherwise I don't see how you can avoid this pseudocode: void f(array1, array2) { /* somehow guaranteed not to alias…

I thought about it, and I realized I didn't know. This is the best discussion I found: http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Aliasing-Assumed... Short answer: they don't. What you wrote is an undefined behavior, just like dereferencing a null pointer in C. If the compiler can't tell statically, then it just assumes they're not aliased. I'm basing this conclusion mainly on this statement from that piece on alias…

Interesting, that sounds equivalent to just assuming "restrict" on all function parameters. If that's true, then C and Fortran aren't fundamentally that different in this respect except that C assumes things can be aliased by default and Fortran assumes they can't.

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

#107

Post by gillianseed » Mon, Jan 09, 2012, 10:59 PM UTC

CountHackulus wrote: post #31

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.

In addition to that, if you're using the Intel compiler, then you can say #pragma ivdep Which tells the compiler that the loop you're writing doesn't have any vector dependencies. Or -fno-fnalias to say that none of the arguments you're passing to a function are aliased. Seems like pretty reasonable ways around the problem. Not to mention things like OpenMP.

iirc the GCC equivalent of ICC's '-fno-fnalias' is '-fargument-noalias'. A pragma would be nice though.

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

#108

Post by derleth » Mon, Jan 09, 2012, 10:59 PM UTC

wvenable wrote: post #84

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…

> C lets you allocate blocks of memory It doesn't even let you do that -- those things are external library calls.

They're standardized, so they are part of the language.

They don't have special syntax, but, then, neither does practically anything you do in Common Lisp, and that's standardized as well.

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

#109

Post by derleth » Mon, Jan 09, 2012, 11:03 PM UTC

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…

> interpreted languages, especially those with weak typing

Dynamic and weak are not the same thing.

Weak typing means you're allowed to break abstractions; C has weak typing, C++ is marginally less weak, and Python has strong typing for its built-in types.

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

#110

Post by stephencanon » Mon, Jan 09, 2012, 11:34 PM UTC

jmaygarden wrote: post #13

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.

This is just totally false. You can lay out your C arrays in exactly the same way that Fortran does, if you choose to. Or you can do something else, if that will give better performance. Tools are just tools; they don't determine what you can do with them. (I write matrix operations for a living, generally in C or Assembly; much of what I write is provably as fast as possible on the target hardware, so it could not possibly be faster if written in Fortran).