[Haskell-cafe] Re: Why can't Haskell be faster?

[Ryan Dickie]

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 <dons at galois.com> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20071031/b30ecb58/attachment-0001.htm