On Sun, 2007-02-25 at 18:57 -0800, Stefan O'Rear wrote: > Haskell, now: > * Very much slower than C > * Very much easier to use than C > * Very easy to interface with C > > So I think we should do the same. It even shows in the Shootout - the > programs that are simultaneously fastest and clearest are not pure > Haskell, but delegate their innermost loops to tuned C libraries (FPS > and GMP).
I should note that FPS is almost completely Haskell code, not C. We use C for things like memcmp, memcpy, memset, reverse_copy, intersperse, maximum, minimum and count. Certainly some of the innards are low level style Haskell, though not the kind that could be replicated in C because we use high level transformations to fuse loop bodies together and wrap them in high performance, low level loop code. This is not the style where we just wrap well tuned C code, this is a style where we generate high performance low level code from a high level spec. This relies on GHC's excellent and programmable optimiser. It's wrong to say that the shootout improvements were only down to improved libraries. The performance of ByteString code improved very significantly between GHC 6.4 and 6.6 and a large part of that was down to optimiser improvements (not just the ForeignPtr rep change). Duncan _______________________________________________ Haskell mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell
