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