So in a few years time when GHC has matured we can expect performance to be on par with current Clean? So Clean is a good approximation to peak performance?
--ryan On 10/31/07, Don Stewart <[EMAIL PROTECTED]> wrote: > > ndmitchell: > > Hi > > > > I've been working on optimising Haskell for a little while > > (http://www-users.cs.york.ac.uk/~ndm/supero/), so here are my thoughts > > on this. The Clean and Haskell languages both reduce to pretty much > > the same Core language, with pretty much the same type system, once > > you get down to it - so I don't think the difference between the > > performance is a language thing, but it is a compiler thing. The > > uniqueness type stuff may give Clean a slight benefit, but I'm not > > sure how much they use that in their analyses. > > > > Both Clean and GHC do strictness analysis - I don't know which one > > does better, but both do quite well. I think Clean has some > > generalised fusion framework, while GHC relies on rules and short-cut > > deforestation. GHC goes through C-- to C or ASM, while Clean has been > > generating native code for a lot longer. GHC is based on the STG > > machine, while Clean is based on the ABC machine - not sure which is > > better, but there are differences there. > > > > My guess is that the native code generator in Clean beats GHC, which > > wouldn't be too surprising as GHC is currently rewriting its CPS and > > Register Allocator to produce better native code. > > Yes, this was my analysis too -- its in the native code gen. Which is > perhaps the main GHC bottleneck now. > > -- Don > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe