Why is Clean faster than Haskell?

Submitted by metaperl on Sun, 10/09/2005 - 4:21pm.

If you compare Clean and Haskell in the Debian shootout, Clean is consistently faster than Haskell. These languages are spitting images of each other, save that Clean has some way of avoiding Monads. In addition, Clean I believe is based on graphs instead of lambda calculus - but both of these compute the same things so why would that matter?

The summary table (at bottom, horribly rendered in Firefox), shows Clean winning 10-0.

Also, which language came first? Clean or Haskell?

Submitted by itkovian on Mon, 10/10/2005 - 3:30pm.

AFAICT, Haskell was first. IIRC, the Clean approach relies on erm uniqueness of something. I should refresh my memory.

Submitted by rinus on Tue, 05/02/2006 - 6:14am.

Clean was first. I was at the FPCA meeting where Clean was presented while at the same meeting it was proposed to think about a new standard functional language since Miranda was under trademark.

Rinus Plasmeijer

Submitted by der_eq on Sun, 10/16/2005 - 11:18am.

I haven't used the language yet, but I've taken a look at the manual. Your claim that it is based on graphs INSTEAD of lambda calculus is wrong. It uses lambda-calculus and encourages graph-rewriting strategies, just like haskell does. In fact, clean seems to borrow a LOT of things from haskell, especially syntax.
From what I've seen, the clean programs in the shoot-out are making heavy use of strict evaluation(everywhere "!" is used) and unboxed types/arrays. So the reason why they appear to be faster could simply result from giving the compiler a lot of hints how to optimize. The same could probably done for the haskell programs.

Submitted by Isaac Gouy on Wed, 12/28/2005 - 2:31pm.

heavy use of strict evaluation... giving the compiler a lot of hints
Clean has a strictness analyzer, so strictness annotations need only be used when the strictness analyzer does not manage to figure out that a function argument can be strict.

(And many Clean programmers simply like to provide explicit type annotations for functions.)

Submitted by doaitse on Fri, 11/04/2005 - 10:28am.

The design of Clean dates back before that of Haskell. Its syntax shows still that it started from a language describing graph-reductions (hence the clumsy notation for types, and the somewhat more complicated way of handling partial parametrisation (but also not having to deal with it implicitly)).

One of the strong points of Clean is the use of uniqueness types, capturing pointers in the implementation "with reference count 1". This allows for a form of static gabage collection. If you take apart a unique value in a pattern match, you may recycle the space taken by the argument value; hence avoiding the overhead of allocation of new space and garbage collecting it later.

Note that in the assigment x:= y+1 you not only specify the new value of x, but also indicate explictly that the old value is no longer needed; it is this scheduling of value availability (explicit garbage colection) that makes imperative programming so complicated, but also which makes Clean programs so efficient.

I do not have precise figures about all the details and the contributions to the overall speed, since the Clean people have, overr the years spent a lot of time in incorporating knowledge about archirectures etc, but I have always expected the uniqueness types to be the great winner, and they have never objected to this point of view.

Submitted by Isaac Gouy on Wed, 12/28/2005 - 2:15pm.

The summary table (at bottom, horribly rendered in Firefox), shows Clean winning 10-0.

Please report specific problems to our Bug Tracker and please describe the problem better than "horribly rendered" (and tell us the OS, the display resolution...)

Submitted by Isaac Gouy on Wed, 12/28/2005 - 2:34pm.

These languages are spitting images of each other...

Maybe some of the Clean programs are better programs than some of the Haskell programs?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.