Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] productivity improvement
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-07-10 (13:12)
From: sebastien FURIC <sebastien.furic@t...>
Subject: Re: [Caml-list] productivity improvement

Dave Mason a écrit :
> 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


 My strange user times are obtained under Cygwin. I forgot to mention I
did the test under Windows NT 4.0 (Intel 200 MHz, 128 MB RAM) using the
last version of Cygwin (hence the last version of time.exe!) and
Objective Caml 3.04. There was no swapping, so sys time is a good
approximation of the time spent by the program to solve the problem.
 It is not very surprising to beat O'Caml using a language that is tuned
to perform lazy computations natively when the problem to solve is lazy!
 More surprising is the fact that the lazy program outperforms a strict
one (written in an imperative style).


To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: