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-22 (15:02)
From: Gerd Stolpmann <info@g...>
Subject: Re: [Caml-list] Is OCaml fast?
Am Montag, den 22.11.2010, 15:36 +0100 schrieb bluestorm:
> On Mon, Nov 22, 2010 at 3:04 PM, Gerd Stolpmann
> <> 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.
> « 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.

It's in deed an unfair comparison: In C they use the Apache runtime
which provides memory pools. This is something that does not extend to
most real world programs.

Because it's ridiculous anyway: Encode the tree in an array. Not really
idiomatic, but in C they also do not use the idiomatic memory management

Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany
Phone: +49-6151-153855                  Fax: +49-6151-997714