On 12/14/07, Dan Piponi <[EMAIL PROTECTED]> wrote: > There have been some great improvements in array handling recently. I > decided to have a look at the assembly language generated by some > simple array manipulation code and understand why C is at least twice > as fast as ghc 6.8.1. One the one hand it was disappointing to see > that the Haskell register allocator seems a bit inept and was loading > data into registers that should never have been spilled out of > registers in the first place.
Someone who knows the backend better than I do can correct me if I'm wrong, but it's my understanding that GHC 6.8.1 doesn't even attempt to do any register allocation on x86. So -- register allocator? What register allocator? But this is being actively worked on; I understand there's code for it in the HEAD. > On the other hand, the code wasn't > fundamentally doing anything weird (eg. it wasn't doing graph > reductions or anything like that, it looked like the sort of loop you > might get from a C compiler). It was a few seconds of fairly mindless > work to fix up the assembly language and make it much faster. And if I > can do it, it means that the next generation of Haskell compiler > should be able to do it too, after all, good freely available methods > to allocate registers do exist. So I'm looking forward to the next > version of GHC matching C's performance for inner loops of array > manipulation code :-) It sounds like Team GHC is thinking about the exact same things you are here: http://hackage.haskell.org/trac/ghc/wiki/Status/Nov07 Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "Science fiction is not predictive; it is descriptive." --Ursula K. Le Guin _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
