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 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------