

Smoking fast Haskell code using GHC's new LLVM codegen - dons
http://donsbot.wordpress.com/2010/02/21/smoking-fast-haskell-code-using-ghcs-new-llvm-codegen/

======
psawaya
Looks like this project began as someone's undergrad thesis. Impressive, to
say the least!

<http://www.cse.unsw.edu.au/~davidt/>

~~~
alexgartrell
I hope Google/Microsoft Research/etc. are writing this guy letters like right
now.

~~~
zitterbewegung
I bet that pg hopes that he will apply to ycombinator.

~~~
GeoJawDguJin
Because... what? Any skilled engineer is somehow automagically also blessed
with entrepreneurial spirit?

------
yason
The best part is that any improvement in LLVM will automagically speed up GHC
as well.

It took me years to realize what a killer project LLVM actually is. I bet this
won't be the last success story for LLVM, either.

------
jmillikin
Wow! I can't wait to try this out. I've been having some problems getting
Haskell to match C's performance in code heavy on buffer mutation, but halving
the Haskell execution time would put it on roughly equal footing.

This provides a lot of encouragement to start some of my rainy-day projects --
my goal is to have a Haskell library with a proof of correctness that can
outperform equivalent C. That day draws ever closer.

~~~
chancho
> that can outperform equivalent C

Isn't that a bit like saying that it "can outperform equivalent assembly"?

And why can you not prove the equivalent C correct? After all, you're doing
that proof by hand either way. A Haskell compiler will only help you prove
that your program is well-typed. If you're mutating buffers then you're in a
monad like IO or ST and the the compiler will throw it's hands up and tell you
that correctness is entirely your problem.

~~~
camccann
In theory, the information a Haskell compiler has available should allow it to
make better optimizations. Things like drastic whole-program optimizations
aren't viable in C because the compiler can't guarantee safety and doing the
optimizations by hand would render the code base completely unreadable. This
is why, for instance, FORTRAN can easily outperform C for certain classes of
program.

In practice, the overhead of supporting Haskell's other features means it's
still generally slower than most popular compiled languages, though not by
much. I have much higher expectations, however, for improvement in Haskell
optimizers than I do for nontrivial static analysis for impure languages
becoming viable.

~~~
DarkShikari
_This is why, for instance, FORTRAN can easily outperform C for certain
classes of program._

Not quite. To quote the master:

    
    
       <pengvado> gcc fails to optimize it because gcc has always sucked at arrays
       <pengvado> that's *the* benefit of fortran
    

The benefit of FORTRAN is due to array and aliasing issues in C, not really
whole-program optimization.

~~~
malkia
hence __restrict

------
srnm
It's interesting that the Haskell project is getting good results.

Go - <http://golang.org/> \- doesn't use LLVM because they claim it is "large
and slow". Search for llvm on <http://golang.org/doc/go_faq.html>

------
wglb
This is seriously cool. The compiler-writer part of me enjoyed * LLVM
transforms the code far more aggressively* and later references to where it
was hard to figure out what the assembly code does.

Wondering if they have done the test where the llvm flag has recompiled ghc.

