News for hackers. Stuff that matters.
Re:Haskell Beats C Using Generalized Stream Fusion [pdf] by jules on Sunday April 07, 2013 @05:59PM (#5508948)
I suspect this comment is at least partially directed at me. Did you read the paper? Excluding some O(1) operations, the goal of the second benchmark is this:

    double s = 0;
    for(int i=0; i<n; i++) s += pow(a[i]-b[i],2);
    return s;
But they did not use this C code. The C code they used made 3 calls to the BLAS library. The end result is that the C code is doing something equivalent to this:

    double x=0, y=0, z=0;
    for(int i=0; i<n; i++) x += a[i]*a[i];
    for(int i=0; i<n; i++) y += a[i]*b[i];
    for(int i=0; i<n; i++) z += b[i]*b[i];
    return x - 2*y + z;
While this does return the same result (assuming infinite precision arithmetic) it is obviously not the way anybody would do it, since it's doing 3 times the work. Even worse, because their code is calling into the BLAS library for each loop, the compiler is explicitly prevented from optimizing the three loops and memory accesses by combining them into one. Note that the Haskell code is doing the efficient single loop. So yes, it is poorly written code.
Re:Haskell Beats C Using Generalized Stream Fusion [pdf] by ky3 on Sunday April 07, 2013 @09:53PM (#5509584)
There are 2 pieces of C benchmarked. The other one computes `a[i]-b[i]` into a temporary array and then makes a single call to BLAS. The speed is roughly half that of Haskell, which dispenses with the space cost of the temporary array.
Re:Haskell Beats C Using Generalized Stream Fusion [pdf] by jules on Monday April 08, 2013 @04:34AM (#5510582)
Yes, you're right, the other C code is even less efficient.
Re:Haskell Beats C Using Generalized Stream Fusion [pdf] by ky3 on Monday April 08, 2013 @03:40PM (#5514005)
Good catch! It's the 3x BLAS that's 1/2 of Haskell's speed.

The 1x BLAS that uses 2x RAM gets shafted, presumably by cache lossage.