[Haskell-cafe] Shootout favoring imperative code

[Chris Kuklewicz]

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 <bfulg at pacbell.net> wrote:
> 
>>--- Sebastian Sylvan <sebastian.sylvan at gmail.com>
>>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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>