Am Montag, den 22.11.2010, 15:36 +0100 schrieb bluestorm: > On Mon, Nov 22, 2010 at 3:04 PM, Gerd Stolpmann > <i...@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 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
