From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id UAA18042; Mon, 11 Jun 2001 20:49:04 +0200 (MET DST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA18247 for ; Mon, 11 Jun 2001 20:49:04 +0200 (MET DST) Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.127.131]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f5BIn3D14762 for ; Mon, 11 Jun 2001 20:49:03 +0200 (MET DST) Received: from beertje.william.bogus (williamc.xs4all.nl [213.84.56.92]) by smtp1.xs4all.nl (8.9.3/8.9.3) with ESMTP id UAA22948; Mon, 11 Jun 2001 20:49:01 +0200 (CEST) Received: (from williamc@localhost) by beertje.william.bogus (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id f5BIrAP03815; Mon, 11 Jun 2001 20:53:10 +0200 X-Authentication-Warning: beertje.william.bogus: williamc set sender to williamc@paneris.org using -f From: William Chesters MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15141.5013.991791.478253@beertje.william.bogus> Date: Mon, 11 Jun 2001 20:53:09 +0200 (CEST) To: caml-list@inria.fr Subject: [Caml-list] the importance of strictness In-Reply-To: <20010611082947.B59230@caddr.com> References: <20010611082947.B59230@caddr.com> X-Mailer: VM 6.75 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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