On Mon, Sep 22, 2008 at 2:07 PM, Bulat Ziganshin
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