[Haskell-cafe] Re: #haskell works

[Tim Chevalier]

On 12/20/07, Simon Marlow <simonmarhaskell at gmail.com> wrote:
>
> That's not entirely true - there is a fairly decent linear-scan register
> allocator in GHC
>
> http://darcs.haskell.org/ghc/compiler/nativeGen/RegAllocLinear.hs
>
> the main bottleneck is not the quality of the register allocation (at
> least, not yet).
>
> The first problem is that in order to get good performance when compiling
> via C we've had to lock various global variables into registers (the heap
> pointer, stack pointer etc.), which leaves too few registers free for
> argument passing on x86, so the stack is used too much.  This is probably
> why people often say that the register allocator sucks - in fact it is
> really the calling convention that sucks.  There is some other stupidness
> such as reloading values from the stack, though.
>
[snipped further reasons]

Thanks for enlightening me. (I had been opting to believe the various
rumor and hearsay floating around rather than actually reading the
source :-)

One reason why I care about this is that over the summer I was trying
to do some performance measurements for House. One of the experiments
I did was measuring how long it took to run a loop of Haskell code
that just did a no-op FFI call. This was still ten times slower than a
loop in C that called the same no-op function. I looked at the
generated code (with the native-code backend), noticed the issues you
mentioned above (reloading values from the stack, and so on), and
concluded that there was probably a good reason why the backend was
being worked on actively. The -fvia-C code wasn't much better.

However, this was with GHC 6.2, so obviously this suggests that
porting House to a newer GHC version might be worthwhile for us to do
:-)

Cheers,
Tim

-- 
Tim Chevalier * catamorphism.org * Often in error, never in doubt
"Dare to be naive."--R. Buckminster Fuller