[Haskell-cafe] Climbing up the shootout...

[Sterling Clover]

At the risk of getting sucked into a silly discussion, I'd like to point out
that the c code uses the following "really simple and naive" function:

http://sourceware.org/cgi-bin/cvsweb.cgi/libc/stdlib/strtol.c?rev=1.42.2.2&content-type=text/x-cvsweb-markup&cvsroot=glibc


http://sourceware.org/cgi-bin/cvsweb.cgi/libc/stdlib/strtol_l.c?rev=1.4.2.3&content-type=text/x-cvsweb-markup&cvsroot=glibc

Oh, and it "simply and naively" loops with the following:

    while (fgets_unlocked (line, MAXLINELEN, stdin))

If Bulat's point is that the shootout has inspired work on Haskell
performance, and in the stdlibs no less, then lovely, and that's all to the
good. Below every high level interface is lots of low level pain.

If his point is anything else, this is getting absurd.

--S

On Mon, Sep 22, 2008 at 8:16 PM, Bulat Ziganshin
<bulat.ziganshin at gmail.com>wrote:

> Hello Don,
>
> Tuesday, September 23, 2008, 3:12:37 AM, you wrote:
>
> >> for the same reason i don't feed 5000 men with 7 breads - it's not my
> >> business ;)
>
> > Ok. So I'll just say: high level, efficient code is an overriding theme
> > of many individuals working on Haskell. Things are better and better
> > each year. We do not stand still.
>
> yes. when we say that things are greatly improving each year, this
> means that they was bad previously ;)
>
> > For example, Bulat cites a paper talking about naive list code from
> > 2002, however, by 2008 we know how to do fusion on lists, so it runs in
> > the same time as low level loops, the technique is implemented and you
> > can download it from hackage,
>
> > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/stream-fusion
>
> someone can ask why this great code isn't used in ghc by default.
> probably it is just work in progress which isn't yet ready to replace
> old slow code. then we can see tha fusion isn't magic wand which
> improves speed of every haskell code that's slower than C one. it just
> makes C-speed code sometimes
>
> > Simon Marlow is busy adding more efficient GC and parallelism to GHC,
> > and there's a summer project to rewrite the native code generator.
>
> well, i'm sais about *current* real situation. if you consider this as
> attack against Haskell developers, it's your mistake. the problem is
> that i many years wrote about slowness of ghc code, every time you
> cosider this as attack and write that in future Haskell will become
> much faster. we still wait for this future, however
>
> > GHC gained pointer tagging in the last release cycle, dramatically
> > reducing the cost of algebraic data types.
>
> 10-20% speed improvement, on average. it's the only real improvement
> (for my own program) i know. i think that ByteString-related libs
> gived more improvements but their use isn't automatic and they doesn't
> help in any situation. they just provide fast library code for solving
> some concrete (although very frequent) situations, such as counting
> lines
>
> > At the same time, we're writing books about how to program "naively" in
> > Haskell, such that your code doesn't suck. That is: training. Teaching
> > people how to write Haskell.
>
> it is what i say - if naive code was effective and automagically
> optimized by ghc, we don't need all those tutorials. anyone looked
> into your tutorial on writing efficient Haskell code, will never say
> that it's easier than in C. so we can conclude that optimized haskell
> programs are several times slower than C ones and need several times
> more to write
>
> > We can see it paying off, where naive code performs very very well,
>
> > http://shootout.alioth.debian.org/gp4/benchmark.php?test=sumcol&lang=all
>
> yes! it's my beloved example of "elegant" haskell code entirely based
> on the readInt function added to ghc libs specifically to win in this
> test. it's implementation is really simple and naive:
>
> -- ---------------------------------------------------------------------
> -- Reading from ByteStrings
>
> -- | readInt reads an Int from the beginning of the ByteString.  If there
> is no
> -- integer at the beginning of the string, it returns Nothing, otherwise
> -- it just returns the int read, and the rest of the string.
> readInt :: ByteString -> Maybe (Int, ByteString)
> readInt as
>    | null as   = Nothing
>    | otherwise =
>        case unsafeHead as of
>            '-' -> loop True  0 0 (unsafeTail as)
>            '+' -> loop False 0 0 (unsafeTail as)
>            _   -> loop False 0 0 as
>
>    where loop :: Bool -> Int -> Int -> ByteString -> Maybe (Int,
> ByteString)
>          STRICT4(loop)
>          loop neg i n ps
>              | null ps   = end neg i n ps
>              | otherwise =
>                  case B.unsafeHead ps of
>                    w | w >= 0x30
>                     && w <= 0x39 -> loop neg (i+1)
>                                          (n * 10 + (fromIntegral w - 0x30))
>                                          (unsafeTail ps)
>                      | otherwise -> end neg i n ps
>
>          end _    0 _ _  = Nothing
>          end True _ n ps = Just (negate n, ps)
>          end _    _ n ps = Just (n, ps)
>
>
>
> when gcc developers will start to add to C libraries functions
> performing shootout benchmarks we will continue this discussion :D
>
> > And lots and lots more people able to write good code for Hackage.
>
> > I find Bulat's outlook rather bleak, and I think it is time to update
> > expectations.
>
> > Progress is beautiful.
>
> :)
>
> --
> Best regards,
>  Bulat                            mailto:Bulat.Ziganshin at gmail.com
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080922/a461ca92/attachment.htm