[Haskell-cafe] Can Haskell outperform C++?

[Ertugrul Söylemez]

Ryan Newton <rrnewton at gmail.com> wrote:

> I think this is a bit of an unfair accusation ("simple-minded").
>  Performance is only relevant to certain domains, sure.  But program
> performance is an entire *industry*.  And I'd argue it's of massive
> importance to the world at large.  Intel has an army of "AE"s
> (application engineers) that go out to other companies to make
> applications perform better.  There are plenty of compute bound
> industries -- i.e. movie companies are limited by what kind of frame
> they can render in ~24 hrs; sequencing centers are limited by certain
> very slow bioinformatics algorithms; you can look almost anywhere you
> like for examples.

I'm sorry for the rough words.  I didn't mean to overgeneralize.  Of
course in certain domains a reasonable performance is desirable, but the
first question you should ask is whether you want high level or low
level performance.  Haskell performs amazingly at the high level and
suboptimal at the low level.

My point is:  If you need C-like performance at a certain spot there is
really no excuse for writing the entire application in C.  Haskell has a
working, powerful enough FFI.  Also idiomatic Haskell code nowadays
performs close to C.  If your code doesn't, chances are that it's not
even idiomatic.  Sorting a list is easy and beautiful in code.  But it's
far from idiomatic.  Using ST with destructive update is also not
idiomatic.  One of my performance masterpieces is the "instinct" AI
library (see Hackage).  It uses only immutable vectors and performs very
heavy Double calculations, yet performs better than the same code with
mutable arrays did.

With a few years of Haskell experience in my backpack I know how to
utilize laziness to get amazing performance for code that most people
would feel must be written with destructively updating loop.  And the
resulting code is just beautiful to read and watch at work, a great
demonstration of the wonders the GHC developers have created.


> As a community I think we have to face the fact that writing the hot
> inner loop of your application as idiomatic Haskell is not [yet] going
> to give you C/Fortran performance off the bat.  Though in some cases
> there's not really anything stopping us but more backend/codegen work
> (I'm thinking of arithmetically intensive loops with scalars only).
> For example, the following Mandel kernel is in many ways the *same* as
> the C version:
>
> https://github.com/simonmar/monad-par/blob/662fa05b2839c8a0a6473dc490ead8dd519ddd1b/examples/src/mandel.hs#L24H
>
> We have the types; we've got strictness (for this loop); but the C
> version was 6X faster when I tested it.

Well, if it's "in many ways the same as C", then again it's probably not
idiomatic Haskell.  I don't know what a Mandel kernel is, so I can't
really tell you how I would write the code without further study.
However, I'm doing a lot of number crunching and my code usually gets
really close to C, and especially for Integer-heavy calculations
actually outperforms C.  I have done the comparison.  Using GMP with all
the features it provides in the mpz_* family of functions is in fact
slower than the same in Haskell (GHC 7.4.1 on Intel i5 64 bits here),
and from my C times I have experience using GMP properly including smart
allocation, etc.

If you want high performance Haskell, writing C in Haskell is /not/ the
solution.  It /will/ result in suboptimal code, likely considerably
slower than the same code in C.


Greets,
Ertugrul

-- 
Key-ID: E5DD8D11 "Ertugrul Soeylemez <es at ertes.de>"
FPrint: BD28 3E3F BE63 BADD 4157  9134 D56A 37FA E5DD 8D11
Keysrv: hkp://subkeys.pgp.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120511/30aa0765/attachment.pgp>