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

[Sebastian Sylvan]

On Tue, Sep 23, 2008 at 2:52 PM, Bulat Ziganshin
<bulat.ziganshin at gmail.com>wrote:

> Hello John,
>
> Tuesday, September 23, 2008, 5:39:17 PM, you wrote:
>
> > Probably not, but I think you completely missed my point. Perhaps I
> > should have originally written "my original C equivalents" rather
> > than "the". You're probably just a better C programmer than me.
>
> well, i don't say about me personnaly or someone else. my points is that
>
> 1) modern C compilers allows to get close-to-asm performance. Haskell don't
> 2) fastest Haskell code is very hard to write, much harder than C one


This is only true for tiny toy benchmarks, not for real applications. For
real applications you're going to have bottle necks in small parts of the
code. So what if that 5-20% of the code has to be written using specialized
techniques to get speed, when you get several times more
productivity/correctness/maintainability in the 80-95% of the code which is
not the bottle neck?

If you're involved in a game where everyone tries to show off how their
programming language deals with the bottle necks then obviously you'd use
these "ugly" techniques to optimize things. It may be that it's more
convenient to write this low level code in C (though I wouldn't say it's
"much" more convenient, slightly more for some cases, less for others), but
the price you pay is that you have to use this low level style for
*everything*. Most of the inconvenience, IMO, is due to syntax not semantics
(specifically having to do "<-" on separate lines in order to read mutable
memory rather than being able to extract the value at the usage site -
though I do believe some syntactic sugar was on the way for that?)

So I think you're wrong to criticize people for showing that Haskell can be
fast. Yes it takes effort (though you can increasingly avoid most of it by
using libraries like ByteString), but nobody is saying that it doesn't.
You're arguing against a straw man. The point is that you *can* get good
performance in Haskell for the parts of your programs which is a bottle
neck. The shootout only tests these parts, which is why the Haskell code in
those submissions is sometimes a bit obscure (though not nearly to the
extent you make out). But that's not how *real* applications look! In real
applications that kind of code would be only a fraction of the total code
base, most of it would be perfectly ordinary Haskell! (whereas in C
everything would be, well C)

Cheers,

-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080923/b482ed31/attachment.htm