Re: [Caml-list] Is OCaml fast?

["Török Edwin" <edwintorok@gmail.com>]

On Mon, 22 Nov 2010 15:36:30 +0100
bluestorm <bluestorm.dylc@gmail.com> wrote:

> On Mon, Nov 22, 2010 at 3:04 PM, Gerd Stolpmann
> <info@gerd-stolpmann.de>wrote:
> 
> > I think the shootout is not a good data source. There are definitely
> > some very poor Ocaml results there, so I'd guess the shootout got
> > recently more attention by enthusiasts of other languages, and the
> > current Ocaml programs there are not very good. (I remember Ocaml
> > was #1 at the shootout a few years ago, faster than C.) So maybe a
> > good opportunity to post better Ocaml solutions there?
> >
> 
> As Sylvain noticed, some (in not most) of the OCaml poor performances
> in the shootout are actually not due to bad OCaml programs, but to
> arbitrary restrictions in the shootout rules. For example, one of the
> bad-performing benchmark for OCaml is the binary-tree benchmark,
> where it is nearly four times slower than C, but on closer inspection
> you discover that this is due to the arbitrary choice to forbid any
> change of the GC parameters. With appropriate GC parameters, the very
> same OCaml program is exactly as fast as C.
> 
> http://shootout.alioth.debian.org/u32/performance.php?test=binarytrees
> 
> « Note: these programs are being measured with *the default initial
> heap size* - the measurements may be very different with a larger
> initial heap size or GC tuning. »
> C version : 12.11 secs
> OCaml version : 47.22 secs
> OCaml version with GC parameters tuned ("interesting alternative"
> section) : 12.67 secs
> 
> 
> Therefore, there is nothing that can be changed to the OCaml
> submission for this benchmark to improve performances, except
> changing the default GC parameters; while this might be a good idea
> in general, changing it only for the sake of shootout-obsessed people
> is ridiculous.

Isn't it possible for the GC to realise its doing too many collections
and increase the minor heap size on its own?
Or isn't it possible to determine at compile time an approximation for
a good heap size, and use that?

Best regards,
--Edwin