[anon1385]

It doesn't seem that meaningful to compare a totally naive C implementation to an optimised Haskell one either. (Well, other than to show how fast C is even without any effort to optimise the code). Saying you have to keep the algorithm the same seems like a rather arbitrary limitation on the comparisons, especially since some algorithms are much less of a natural fit in some languages (see: quicksort in Haskell vs C [1]).

I would suggest it's best to show (at least) 4 versions of the code to compare two language: the naive implementation in both languages, and the really optimised version in both languages (plus intermediate levels of optimisation if you feel dedicated). That gives a picture of how fast the typical code one would write will be, as well as the potential for optimisation if you are experiencing bottlenecks, and how much effort it takes to optimise the code.

[1] http://augustss.blogspot.co.uk/2007/08/quicksort-in-haskell-...

[lelf]

> totally naive C implementation to an optimised Haskell one either.

Haskell version is totally naïve. That's the point.

[anon1385]

The first version that takes 5.9 seconds is naive. The second one certainly isn't, and the third one is based on cleaning up the second version with the use of some library code. As somebody who isn't a Haskell programmer it isn't clear to me at all that anybody would write the final version of the code if they weren't trying to optimise it. Maybe they would but the article doesn't really argue that case and it appears that stream-fusion isn't a part of the language/standard libraries (you have to install it with cabal).

Once you start modifying code to make it run faster it's no longer a 'naive' implementation. No matter how nice or logical you think those transformations are.

I'm not saying you can't compare the stream-fusion version against other languages, just that it's highly disingenuous to optimise the Haskell code with some external libraries but then argue that optimisations of the C version are unfair.

[mietek]

If anyone is being disingenuous here, it's you.

The first version [1] is simple and slow. The second version [2] is complex and fast.

The third, fast version [3] is identical to the first, simple version, with list processing functions imported from the `stream-fusion` package. This is the entire point of this article.

The only transformation shown is purely mechanical (prepending symbol names with the qualified import prefix `S.`), and even this is not required (as `Prelude` could have been imported `hiding` the appropriate symbol names instead).

[1]: http://www.mit.edu/~mtikekar/posts/src/collatz.hs

[2]: http://www.mit.edu/~mtikekar/posts/src/collatz1.hs

[3]: http://www.mit.edu/~mtikekar/posts/src/collatz2.hs

[vinkelhake]

Are there downsides to using the stream-fusion package? If not, why hasn't it been made the default so that the first naive version is fast?

[mietek]

As I understand, stream fusion is still subject of active research. A paper showing generalised stream fusion in Haskell was submitted to this year's ICFP.

There is also no benevolent dictator in charge of Haskell.

http://research.microsoft.com/en-us/um/people/simonpj/papers...

http://www.reddit.com/r/haskell/comments/1br0ls/haskell_beat...

[carterschonwald]

indeed. The generalized stream fusion work is about lifting pointwise operations to their SIMD vectorized analogue.

Likewise, stream fusion isn't always a win! Stream fusion and its siblings are great for pointwise operations, but aren't always a good idea for computations with heavy reuse, like nested convolutions or performant matrix multipy

[dons]

Complexity of concatMap operations. Nested things don't always fuse.

If you want to use fusion, the best place is the `vector` package.

[tel]

I think the idea is that there are many more optimizations that could be performed, but this "naïve" version is still very idiomatic and high level.