caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* [Caml-list] the importance of strictness
@ 2001-06-11 15:29 Miles Egan
  2001-06-11 18:53 ` William Chesters
  0 siblings, 1 reply; 2+ messages in thread
From: Miles Egan @ 2001-06-11 15:29 UTC (permalink / raw)
  To: caml-list

While perusing the results of the last several ICFP contests, I've been struck
by the fact that teams using Haskell often manage to write correct programs,
they are almost always slower than the Ocaml entries.  My impression is that the
Ocaml advantage is at least partially due to a more efficient compiler.  Is this
because more effort has been devoted to optimizing the Ocaml compiler or is it
because a strict language is simpler to implement and leaves more room for
optimization?

-- 
miles
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr


^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Caml-list] the importance of strictness
  2001-06-11 15:29 [Caml-list] the importance of strictness Miles Egan
@ 2001-06-11 18:53 ` William Chesters
  0 siblings, 0 replies; 2+ messages in thread
From: William Chesters @ 2001-06-11 18:53 UTC (permalink / raw)
  To: caml-list

Miles Egan writes:
 > While perusing the results of the last several ICFP contests, I've been struck
 > by the fact that teams using Haskell often manage to write correct programs,
 > they are almost always slower than the Ocaml entries.  My impression is that the
 > Ocaml advantage is at least partially due to a more efficient compiler.  Is this
 > because more effort has been devoted to optimizing the Ocaml compiler or is it
 > because a strict language is simpler to implement and leaves more room for
 > optimization?

A bit of both.  To make really efficient Haskell you have to work to
help the compiler strictify your code (and often to deforest it using
the rewrite rules).  Basically the semantics of lazy lambda calculus
are a rotten match for really existing hardware and they simply cannot
be implemented efficiently without transformations the compiler won't
be able to do for itself for the forseeable future.

(Unboxing seems to be pretty much as good as ocaml's though.)

Then the backend is still much less good than ocaml's, even using
-via-C as they recommend: their generated C tries to micromanage the
stack rather than just declaring values as variables, with the result
that gcc, at least, puts nothing in a register.

>From my brief experiemnts a few weekends ago,
William
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2001-06-11 18:49 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-06-11 15:29 [Caml-list] the importance of strictness Miles Egan
2001-06-11 18:53 ` William Chesters

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).