On 12/20/07, Simon Marlow <[EMAIL PROTECTED]> 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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe