[Haskell-cafe] Re: A suggestion for the next high profile Haskell
Donald Bruce Stewart
dons at cse.unsw.edu.au
Sun Dec 17 19:51:48 EST 2006
> Quoting Bulat Ziganshin <bulat.ziganshin at gmail.com>:
> > Haskell can't provide fast execution speed unless very low-level
> > programming style is used (which is much harder to do in Haskell than in C,
> > see one of my last messages for example) AND jhc compiler is used
I have to dispute this Bulat's characterisation here. We can solve lots
of nice problems and have high performance *right now*. Particularly
concurrency problems, and ones involving streams of bytestrings.
No need to leave the safety of GHC either, nor resort to low level evil
This obsession with mutable-variable, imperative code is unhealthy, Bulat ;)
> The PGP format is heavily character stream-based. We know how horrible
> the performance of character streams are in Haskell. On one hand, this
> would be an excellent test case. On the other hand, performance would
> indeed suck now.
Unless you used a stream of lazy bytestrings!
As Duncan did for his pure gzip and bzip2 bindings:
compress, decompress :: ByteString -> ByteString
With underlying stream fusion, you keep the nice high level code. And no
imperative gunk required! I see no reason a PGP tool couldn't be
P.S. The comments on this thread makes me think that the state of the
art high perf programming in Haskell isn't widely known. Bulat-style
imperative Haskell is rarely (ever?) needed in the GHC 6.6 Haskell code
I'm writing in these days. Solving large data problems is feasible
*right now* using bytestrings.
Trying to write code using an imperative style is likely to do more harm
than good, and certainly not something to suggest to beginners on the
mailing list ;)
More information about the Haskell-Cafe