On 31/10/2007, Peter Hercek <[EMAIL PROTECTED]> wrote: > Add to that better unbox / box annotations, this may make even > bigger difference than the strictness stuff because it allows > you to avoid a lot of indirect references do data. > > Anyway, if Haskell would do some kind of whole program analyzes > and transformations it probably can mitigate all the problems > to a certain degree. >
So, I might assert that it is not a problem of the Haskell language itself, it is a problem with the compiler. Which means that with enough effort it would be possible for the compiler to generate compiled code with performance as good as Clean. > So the slowness of Haskell (compared to Clean) is consequence of > its type system. OK, I'll stop, I did not write Clean nor Haskell > optimizers or stuff like that :-D > type system? Why is that? Shouldn't type system in fact speed up the generated code, since it will know all types at compile time? > Peter. > > Peter Hercek wrote: > > I'm curious what experts think too. > > > > So far I just guess it is because of clean type system getting > > better hints for optimizations: > > > > * it is easy to mark stuff strict (even in function signatures > > etc), so it is possible to save on unnecessary CAF creations > > > > * uniqueness types allow to do in-place modifications (instead > > of creating a copy of an object on heap and modifying the copy), > > so you save GC time and also improve cache hit performance > > > > Peter. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe