[Haskell-cafe] Shootout favoring imperative code
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
More information about the Haskell-Cafe