News for hackers. Stuff that matters.
Re:Haskell Beats C Using Generalized Stream Fusion [pdf] by CJefferson on Sunday April 07, 2013 @11:36AM (#5507523)
While it is interesting to see generalised stream fusion, the conclusions are that Haskell is still half the speed of C++.

Also, looking at the results most of the performance comes from which library you are using, and how well it is optimised. No compiler is good enough to do what the good libraries do.

Re:Haskell Beats C Using Generalized Stream Fusion [pdf] by gngeal on Sunday April 07, 2013 @01:19PM (#5507858)
"No compiler is good enough to do what the good libraries do."

That's nonsense. And if you take a look, say, at NumPy, which uses heavily tuned BLAS/LAPACK code, and Numexpr, which uses the "compile the snippet and run it" approach, you'll see why. Libraries won't save your performance if you can't optimize across procedure and module boundaries.

Re:Haskell Beats C Using Generalized Stream Fusion [pdf] by ori_b on Sunday April 07, 2013 @05:57PM (#5508938)
Which is why C and C++ under most state of the art compilers support link time optimization.
Re:Haskell Beats C Using Generalized Stream Fusion [pdf] by gngeal on Monday April 08, 2013 @06:17AM (#5510879)
That won't help you much, if you, say, need the fusion of matrix operations I mentioned.
Re:Haskell Beats C Using Generalized Stream Fusion [pdf] by miga on Sunday April 07, 2013 @12:16PM (#5507635)
Stream fusion is an optimization framework that is (to my knowledge) defined in the library, but common to most sequence types in Haskell.