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 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 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.

On 31/10/2007, Peter Hercek 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

Paulo J. Matos wrote:

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?

The *existence* of a type system is helpful to the compiler. Peter was referring to the differences between haskell and clean. Specifically, clean's uniqueness types allow for a certain kind of zero-copy mutation optimisation which is much harder for a haskell compiler to automatically infer. It's not clear to me that it's actually worth it, but I think that's the point at issue. I can *imagine* algorithms in which copying is actually faster than mutation, if copying gives you better locality. Jules

Robin Green wrote:

On Wed, 31 Oct 2007 14:17:13 +0000 Jules Bean wrote:

...

Specifically, clean's uniqueness types allow for a certain kind of zero-copy mutation optimisation which is much harder for a haskell compiler to automatically infer. It's not clear to me that it's actually worth it, but I think that's the point at issue. I can *imagine* algorithms in which copying is actually faster than mutation, if copying gives you better locality.

If you want in-place update in Haskell, you can use the ST monad, or IORefs. Yes, you have to refactor code, but anecdotally, uniqueness types aren't without problems either - you can make one small change and your code no longer satisfies the uniqueness condition.

IORefs don't give you in-place update. They give you mutation, but new values are still allocated in new heap. foo <- newIORef "hi" writeIORef foo "bye" -- "bye" is a new string, allocated in new heap. the only thing that got -- mutated was a pointer. STArrays and certain IO Arrays give you in-place update, though. Jules

bf3:

Are these benchmarks still up-to-date? When I started learning FP, I had to choose between Haskell and Clean, so I made a couple of little programs in both. GHC 6.6.1 with -O was faster in most cases, sometimes a lot faster... I don't have the source code anymore, but it was based on the book "The Haskell road to math & logic".

Could be in the better Haskell libraries? We only really have the shootout programs, which are very small.

However, the Clean compiler itself is really fast, which is nice, it reminds me to the feeling I had with Turbo Pascal under DOS :-) I find GHC rather slow in compilation. But that is another topic of course.

I find it comforting that GHC thinks so hard about my code. :) -- Don