[Haskell-cafe] Climbing up the shootout...

Simon Brenner olsner at gmail.com
Mon Sep 22 13:03:52 EDT 2008


On Mon, Sep 22, 2008 at 2:07 PM, Bulat Ziganshin
<bulat.ziganshin at gmail.com> wrote:
> this overall test is uselles for speed comparison. afair, there are
> only 2-3 programs whose speed isn't heavily depend on libraries. in
> DNA test, for example, Tcl (or PHP?) was leader just because it has
> better regexp library

On the regex-dna benchmark, I'll have to agree. It's unfortunate to
have a benchmark so dependent on the set of libraries included in the
distribution, and e.g. Text.Regex.PCRE kicks Text.Regex.Posix's behind
in this benchmark - but we probably can't use it only because one's
bundled and the other isn't. Maybe we could roll our own regexp engine
for this specific benchmark though (for example, Text.Regex.TDFA is
within 10% or something of PCRE and AFAIK pure Haskell - a customized
and downsized version of that could probably be made quite
competitive).

> to make things even funnier, this test allows to use libs bundled to
> compiler, but not 3rd-arty ones. so ghc (not Haskell!) what includes
> more built-in libs than gcc looks like a leader. of course, noone uses
> bare ghc or gcc in real world

I don't think it's ever claimed that the shootout is a fair benchmark
of real-world problems :D

> 2) there uis a fashion in Haskell world to write for shootout in the
> very low-level style, which isn't actually used in real programming
> and actually understood only by a few "wizards" developing
> high-performance haskell code

That is certainly the case with a few of the benchmark
implementations, and in the past it was required to get the
performance. In some cases it's also due simply to the haskell
implementation being a straight-from-C port - which necessitates using
pointers and putting everything in IO etc... Some of that haskell code
is among the least readable code I've ever read (see e.g. the fannkuch
benchmark at http://shootout.alioth.debian.org/u64q/benchmark.php?test=fannkuch&lang=ghc).
But that's what you get when porting pointer-rich C code directly into
Haskell :)

With bytestrings, unboxed arrays, light-weight threads and other
tricks, we can usually replace all those ugly low-level programs with
nice high-level haskell ones - it's all about allowing the compiler to
do good stuff with naive (or at least naive-looking) code, and
teaching it how to cut through the abstractions. (As well as using the
right abstractions, of course...)

// Simon


More information about the Haskell-Cafe mailing list