[Haskell-cafe] Shootout favoring imperative code

Sebastian Sylvan sebastian.sylvan at gmail.com
Sat Jan 7 08:40:08 EST 2006

On 1/6/06, Udo Stenzel <u.stenzel at web.de> wrote:
> 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.

It would be neat if the PackedString library contained functions such
as hGetLine etc. It does have a function for reading from a buffer,
but it won't stop at a newline...
But yeah, fast string manipulation is difficult when using a
linked-list representation...

Sebastian Sylvan
UIN: 44640862

More information about the Haskell-Cafe mailing list