[Haskell-cafe] Re[4]: [Haskell] Google Summer of Code

[Don Stewart]

bulat.ziganshin:
> Hello John,
> 
> Wednesday, February 11, 2009, 11:55:47 PM, you wrote:
> 
> >> it's exactly example of tight loop. and let's compare HP code written
> >> for this task with analogous code written in C. i expect that haskell
> >> code is much more complex
> 
> > I think it's fair to point out that tight loops are nearly always the
> > biggest bottlenecks of code, so generating good code for tight loops
> > is pretty important.
> 
> it's important, but doesnt't make whole game. and while i said that
> ghc improved tight loops compilation, this doesn't mean that it
> becomes the same as in gcc. it just started to put loop variables into
> register
> 
> > And ghc is still making large improvements with
> > each release, whereas gcc isn't likely to get significantly better.
> 
> yes, it's close to perfect
> 
> >> afaiu, it's 20-line equivalent of 2-line C code:
> >>
> >> for (i=...)
> >>  a[i] = b[i]
> >>
> >> does this need any more comments?
> 
> > I think you've misunderstood my code.  Look at Oleg's IterateeM and
> > see if you think that's really all it's doing.
> 
> what else does the code that you've citated? you are wrote that it
> just copies 16-bit words into doubles
> 
> > Use libsndfile for comparison.  http://www.mega-nerd.com/libsndfile/.
> 
> it's one method of miscomparing haskell to C - compare hand-tuned
> haskell code with some C code which may be just not optimal. ig you
> want to make fair comparison, you should write best code in both
> languages
> 
> > I actually haven't looked at the code, although it's very highly
> > regarded in the audio community (and I've seen the author post on this
> > list on occasion).  Using libsndfile-1.0.18:
> >  wc wav.c
> >     1786    7833   57922 wav.c
> 
> > compared to my source:
> > wc Wave.hs
> >      412    2215   15472 Wave.hs
> 
> > And there you are.  I will admit that I have implemented the entire
> > wave spec, but only because of lack of time.
> 
> when you don't need speed, you may write more compact code in haskell
> than in C. so the best way is to split your task into
> speed-critical part and the rest and use C++ for the first and Haskell
> for the second


I think what's frustrating about this continued dialogue with Bulat re.
performance is that ,

    a) the experience he bases his remarks upon was several year ago
    b) he's making blanket generic statements, using that old data
    d) a lot of people have written a lot of fast code without trouble
    c) he's not acknowledging the great improvements over this time

So its very difficult to have these conversations. They're stuck in the
same old pattern.

Meanwhile, GHC keeps getting smarter and smarter. 

Bulat: time to update your results! 

Check out what GHC is doing these days, and come back with an analysis
of what still needs to be improved.  We can't wait to hear!

-- Don