
Brent Fulgham wrote:
--- Chris Kuklewicz
wrote: 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).
It's created by catting the example file together multiple times. I'll update the page to be more clear about this, and I can send you the actual file used on the test machine if you want.
That is what I did as a hack. Nice to see I guessed right. Right now I use a 1,680,000 line (concatenated) version to get the processing times large enough to discern small improvements.
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.
Yes -- it was designed as a test of the standard I/O system.
-Brent
I assumed that that I could use getContents, like the previously accepted Haskell entry. It returns the entire stdin as a single (lazy) string, so it is technically not "line oriented". But it is certainly a "standard I/O system" for Haskell. I'll submit my improved version soon. -- Chris