Am Dienstag, den 23.11.2010, 17:53 +0000 schrieb Isaac Gouy:
> Christophe TROESTLER <Christophe.Troestler+ocaml <at> umh.ac.be> writes:
>
> >
> > On Tue, 23 Nov 2010 02:03:48 +0000, Isaac Gouy wrote:
> > >
> > > > C version : 12.11 secs
> > > > OCaml version : 47.22 secs
> > > > OCaml version with GC parameters tuned ("interesting alternative"
> > > section) : 12.67 secs
> > >
> > > And of course you know because that GC tuned OCaml program is shown
> > > on the
> > > benchmarks game website
> > > http://shootout.alioth.debian.org/u32/program.php?test=binarytrees&;
> > > lang=ocaml&id=1
> >
> > Since you are here, please explain why C can use memory pools and vec
> > tor instructions but tuning the GC of OCaml ― although it is part of
> > the standard library ― is considered an “alternative”.
>
>
> You seem to be suggesting that "tuning the GC" is considered "alternative"
> only
> for OCaml programs.
>
> You seem to be suggesting that "tuning the GC" is considered "alternative" for
> every task.
>
> Neither is true.
>
> You seem to be suggesting some kind of equivalence between vector instructions
> and "tuning the GC".
> You haven't said why they should be considered equivalent.
>
> Nor have you said why you think C should not be allowed to use memory pools.
Quite easy: because you are comparing results that cannot be compared.
The reader of this benchmark (binary trees) might have the impression
that C is generally that fast - however, this would be no longer true if
these binary trees were used as library in a bigger program where using
memory pools is inappropriate, e.g. because the data managed by the
binary trees has an unpredictable lifetime.
I do not say that it is complete nonsense to do this comparison, but
only that it is more specific than a reader would assume. The innocent
reader expects a comparison of binary tree performance, not of methods
of managing memory (and this is it finally). The true name of this test
should be "manage_many_small_memory_cells_where_pools_are_allowed". (It
would be actually interesting to compare various versions of this test
with different memory management methods.)
Gerd
>
>
>
>
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
--
------------------------------------------------------------
Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany
g...@gerd-stolpmann.de http://www.gerd-stolpmann.de
Phone: +49-6151-153855 Fax: +49-6151-997714
------------------------------------------------------------
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
