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 PAA05019; Wed, 10 Jul 2002 15:07:56 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA05014 for caml-list@pauillac.inria.fr; Wed, 10 Jul 2002 15:07:56 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id NAA03857 for ; Wed, 10 Jul 2002 13:58:34 +0200 (MET DST) Received: from sarg.ryerson.ca (sarg.ryerson.ca [141.117.18.117]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g6ABwXb05393 for ; Wed, 10 Jul 2002 13:58:34 +0200 (MET DST) Received: from sarg.ryerson.ca (dmason@localhost) by sarg.ryerson.ca (8.11.2/8.11.2) with ESMTP id g6ABwVm25582; Wed, 10 Jul 2002 07:58:31 -0400 Message-Id: <200207101158.g6ABwVm25582@sarg.ryerson.ca> To: "sebastien FURIC" Cc: caml-list@inria.fr Subject: Re: [Caml-list] productivity improvement In-reply-to: Your message of "Wed, 10 Jul 2002 12:02:38 +0200." <3D2C063E.25EA1D8D@tni.fr> User-Agent: EMH/1.10.0 SEMI/1.13.7 (Awazu) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YlTj4xGyhC?=) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (alpha-redhat-linux) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Date: Wed, 10 Jul 2002 07:58:31 -0400 From: Dave Mason Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Further to my comment on benchmarking... I just ran your ocaml lazy version, and got: real 14m15.124s user 13m26.769s sys 0m2.510s This on a 533MHz Alpha with 3/4GB of RAM. There is no swapping. Even when I compile it with the optimizing compiler, I get: real 9m8.763s user 8m51.626s sys 0m1.667s Based on the (small) differences between the byte-code version and the optimized version, I hypothesize that a large amount of that time is spent in garbage collection. This looks like a perfect garbage-collector stress test! My guess for why Clean does well suggests a garbage collector better tuned to the problem, but more importantly, a much more efficient handling of laziness. I suspect you'd see similar results for this problem in Haskell. Of course that doesn't mean Clean or Haskell will beat OCaml at most, or even many, other benchmarks. But when laziness is inherent in a solution, expect lazy languages to do much better than eager languages. ../Dave ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners