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
Is OCaml fast?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2010-11-27 (15:59)
From: Christophe Raffalli <craff73@g...>
Subject: Re: [Caml-list] Re: Is OCaml fast?
> To the extent that this rule is the same for all languages and that most
> languages on the shootout are also garbage collected, I think OCaml's
> problem with this benchmark do point at a weakness of the current
> GC code.
This is untrue ... the bintree example, is just bad in OCaml because the
value of the minor heap size is the correct value for reactive programs
where you want fast minor GC slice, because they interrupt the program ...

Maybe the Gc library could provide reasonable default settings for both
accessible via a simple function GC.is_reactive : bool -> unit ... And
the shootout
would allow to call such a function ?

Clearly, all benchmarks which just measure speed and space should use a
minor heap size (except if reactive communication between processes is
important in the

More importantly, there is little hope to discover at runtime that a
program is
a reactive one ... In other words there is no hope for a perfect GC for
all situations.
So it is a good thing that OCaml allows tuning the GC.

Moreover, even when you automatically tune the GC (like changing the
number of generations in some modern GC) you do it based on past
observation of the behavior of your program ... and the behavior of the
program can change just after you changed some GC parameters ... So
begin able to help the GC, in a comprehensive way,
is good ...