[Haskell-cafe] Fannkuch Entry
sebastian.sylvan at gmail.com
Fri Jan 6 11:48:28 EST 2006
On 1/6/06, David F. Place <d at vidplace.com> wrote:
> Hi All,
> I've been enjoying following the thread about the "shootout" programs
> and trying to understand the performance of the entries, especially
> the Fannkuch benchmark. I've been comparing Sebastion's and
> Bertram's proposals found on the wiki. On my machine (PowerBook g4
> (512M), GHC 6.4.1), Bertam's is about 3x faster. I think the main
> reason for the difference is that Bertram's conses much less and
> keeps much less data live on the heap.
> I don't find Bertram's version especially hard to read. I tripped on
> '>>=', but it was easy to look it up. You can substitute "concatMap"
> without penalty if you hate monads. The technique used in Bertram's
> `flop' is known to anyone who has been introduced to streams.
> I think Bertram solution is an idiomatic "engineered" Haskell program.
Yes, Bertram's is faster. But it's also a lot less readable, IMO. It
uses explicit recursions instead of standard library functions, and
extra complexities here and there. The usage of >>= (and the list
monad) is one example, but have a look at the flop function. I can
only speak for myself but to me that's pretty difficult to understand,
and I really doubt that anyone who hasn't done a significant amount of
Haskell programming will grasp it at all.
So like it says on the wiki, I wrote the most obvious and clear
solution I could come up with, which proved to be several times faster
than the existing Haskell solution in the shootout. I do not claim
that it's the fastest solution possible (in fact, I knew it wasn't)
but it does *no* optimizations that hurt clarity (by design!).
If you think that Bertrams solution is readible then great, then we
have an optimized version that's somewhat readible (personally, I
think it's pretty rough reading, and I can only imagine how a
non-Haskeller would feel). If it turns out that the fastest we comes
up with uses Ptrs and is written entirely in the IO monad, then we're
not so lucky.
More information about the Haskell-Cafe