[Haskell-cafe] Shootout favoring imperative code
sebastian.sylvan at gmail.com
Wed Jan 4 12:16:15 EST 2006
On 1/4/06, Scherrer, Chad <Chad.Scherrer at pnl.gov> wrote:
> Several people on this list have said that the shootout favors imperative code. Is this really the case? Why is it Clean seems to have no trouble (for the incomplete set of benchmarks that are written in it)?
> How difficult would it be to translate the Clean algorithms into Haskell?
IMO, the problem isn't that it's not *possible* to make the Haskell
versions as fast at the C versions. You just write them in an
imperative style using pointers, peek, poke etc. However, most people
don't use Haskell for it's facilites for writing C-style code.
Some of the problems seem to be heavily geared towards an imperative
*implementation*, meaning that a Haskell version is hardly idiomatic
Haskell (and as such I , and I suspect otehrs, really have no
inclination to work on it).
Take the fannuch benchmark for instance. Part of it is to generate
input data (all permutations of a sequence). It would be better to not
require the program to print out the first 30 lists from the input
data, since that places additional (completely unneeded) restrictions
on how to implement the program (and leads to an unnecessarily ugly
implementation if you generate the input in a non-imperative fashion).
I assume it's no coincidence that this sequence exactly matches the
"straightforward" way to generate permutations in C.
Now, there is some value to restrict implementaiton in *some* cases.
For instance if you want to test the speed of a function call with a
recursive algorithm, you need to enforce that the algorithm is written
So in conclusion: By placing too many requirements on the
implementations of the algorithms you make the benchmarks completely
useless for languages that aren't C-ish in nature. It all degenerates
into "are there enough programmers who are willing to spend time
writing C in Haskell?" and not how easy it is to solve the problems in
Haskell, and how fast the results are.
I should note that there are a few good "unbiased" benchmarks in there
as well (such as chamenos and others) which place very little
restriction on implementation and just says what needs to be done...
I should also note that I don't think these benchmarks mean anything
at all. It would be better to test, say, the best possible solutions
for some of the ICFP programming contests, for example. They say a lot
more about real-world speed.
More information about the Haskell-Cafe