
Also about sum-file: They do not reveal what the actual 8k test file contains. So there is no way to reproduce the benchmark locally for testing. (One can learn it totals 400000, but since negative numbers are allowed, this does not help much). The problem can even be solved in one line with (g)awk. Apparantly it is bottlenecked by parsing strings into integers, but they specify "Programs should use built-in line-oriented I/O functions rather than custom-code." which means the programmer's hands are completely tied. So it is just a benchmark of the build-in library function, not of any algorithm the programmer provides. There is no need to beat a dead horse, though. This benchmark sets out to test fgets / atoi, and that is all. There are better benchmarks to spend time on. -- Chris Sebastian Sylvan wrote:
On 1/4/06, Brent Fulgham
wrote: --- Sebastian Sylvan
wrote: 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).
I agree that several benchmarks suffer from this problem, but we have been trying to change this where possible.
A good example of an unfair benchmark that Udo Stenzel noted over at the shootout haskell wiki is "sum-file". Here you specify that no line is ever more than 128 characters long. What's the purpose of doing that? Clearly it's to make life easier for C programmers, is it not? (do C programs never have to deal with the "real world" where such assumptions can't be made?). Furthermore an 128 digit number in base 10 would occupy 53 bytes, but the C (and most other) implementations assume that it will all fit within one machine word, which is obviously against the spec (the only thing the spec says about size of the numbers is that it's at most 127 digits, since one char is a newline, so the implementation must assume the worst about the size of the numbers to be compliant).
This is a one-liner in idiomatic Haskell (getContents >>= print . sum . map read . lines), but since there are restrictions specifically tailored to make life easier for lower level languages, the Haskell submission must resort to all sorts of "hacks" to compete (to circumvent the high-level general tools available). Unfair!
/S
-- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe