[Haskell-cafe] Shootout favoring imperative code

Udo Stenzel u.stenzel at web.de
Thu Jan 5 18:41:45 EST 2006

Sebastian Sylvan wrote:
> On 1/5/06, Chris Kuklewicz <haskell at list.mightyreason.com> wrote:
> > 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.
> I agree. The benchmark really is about how fast you can call low-level
> IO system calls. But since Haskell is a high-level language it's
> natural that it's a bit difficult to get access to these unsafe (but
> fast) low-level functions.

There's probably a bit more to it.  First off, one could legitimately
argue that (liftM lines getContents) is the Haskell way to do line
oriented IO.  The real question is, why does the fast solution have to
be ugly

> foreign import ccall "stdio.h" fgets :: CString -> Int -> Ptr CFile ->IO CString
> foreign import ccall safe "stdlib.h" atoi :: CString -> Int
> foreign import ccall safe "stdio.h &(*stdin)" c_stdin :: Ptr CFile

and why does the idiomatic solution have to be slow?

| main = print . sum . map read . lines =<< getContents

The biggest hit is probably the construction of a huge String as linked
list, which cannot be deforested away (not with the foldr/build
mechanism anyway).  Assuming we find a better representation for
Strings, we could make some headway here and in many other benchmarks.

So I think, just by replacing String and along with it getContents,
lines and read, we will get competitive speed and retain the ability to
handle arbitrarily long lines.  Of course, the shootout wouldn't care
for a feature that is otherwise quite important in practice...  Anyway,
I'll try try to come up with something and then follow up on this.

A man always needs to remember one thing about a beautiful woman:
Somewhere, somebody's tired of her.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.haskell.org//pipermail/haskell-cafe/attachments/20060106/7a6f5f09/attachment.bin

More information about the Haskell-Cafe mailing list