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

[Bulat Ziganshin]

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