Am Montag, den 22.11.2010, 15:36 +0100 schrieb bluestorm:
> 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.

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
(malloc/free).

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------