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