On 1/4/06, Scherrer, Chad
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)?
http://shootout.alioth.debian.org/clean.php
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 with recursion. 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. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862