From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 778D2BBAF for ; Tue, 23 Nov 2010 20:24:58 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMBAGOj60zU4xEKkGdsb2JhbACDTpBgjjQVAQEBAQkJDAcRAx+IK6VAkHUCgSCDNnMEhw2GYA X-IronPort-AV: E=Sophos;i="4.59,243,1288566000"; d="scan'208";a="80070007" Received: from moutng.kundenserver.de ([212.227.17.10]) by mail4-smtp-sop.national.inria.fr with ESMTP; 23 Nov 2010 20:24:58 +0100 Received: from office1.lan.sumadev.de (dslb-094-219-215-222.pools.arcor-ip.net [94.219.215.222]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0Le9EG-1OeEl21Y56-00q3zj; Tue, 23 Nov 2010 20:24:48 +0100 Received: from [192.168.5.106] (dslb-094-219-215-222.pools.arcor-ip.net [94.219.215.222]) by office1.lan.sumadev.de (Postfix) with ESMTPA id B90295F701; Tue, 23 Nov 2010 20:24:47 +0100 (CET) Subject: Re: [Caml-list] Re: Is OCaml fast? From: Gerd Stolpmann To: Isaac Gouy Cc: caml-list@inria.fr In-Reply-To: References: <1290434674.16005.354.camel@thinkpad> <20101123.113733.2059974256209184038.Christophe.Troestler+ocaml@umons.ac.be> Content-Type: text/plain; charset="UTF-8" Date: Tue, 23 Nov 2010 20:24:46 +0100 Message-ID: <1290540286.16005.411.camel@thinkpad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V02:K0:A2UUglwYCYw/FBKD3K8dhb2WuUcLoQV9rgnyxfVRvOy 5rvg6hjhEO5/YIE7uROm0QhpeZiVAOPwDF+WDRyo7qp+DNorqI 34qLKJ8WiCnwkrrGxd5/+MoVV/R73qfMMoQhYSaERvpckoE9xz Ad8i5Dm/IanT4AKzAtvdG9cjNhOQhGPX7oLDcGTy4pVCwwHv7K iQFmLjEGpHWSp2ZqqP2BA== X-Spam: no; 0.00; ocaml:01 gerd:01 stolpmann:01 christophe:01 troestler:01 christophe:01 troestler:01 ocaml:01 gerd:01 beginner's:01 bug:01 stolpmann:01 darmstadt:01 6151:01 6151:01 Am Dienstag, den 23.11.2010, 17:53 +0000 schrieb Isaac Gouy: > Christophe TROESTLER umh.ac.be> writes= : >=20 > >=20 > > 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"= =20 > > > section) : 12.67 secs > > > > > > And of course you know because that GC tuned OCaml program is shown= =20 > > > on the > > > benchmarks game website=20 > > > http://shootout.alioth.debian.org/u32/program.php?test=3Dbinarytree= s&=20 > > > lang=3Docaml&id=3D1 > >=20 > > Since you are here, please explain why C can use memory pools and vec= =20 > > tor instructions but tuning the GC of OCaml =E2=80=95 although it is = part of =20 > > the standard library =E2=80=95 is considered an =E2=80=9Calternative=E2= =80=9D. >=20 >=20 > You seem to be suggesting that "tuning the GC" is considered "alternati= ve" only > for OCaml programs. >=20 > You seem to be suggesting that "tuning the GC" is considered "alternati= ve" for > every task. >=20 > Neither is true. >=20 > You seem to be suggesting some kind of equivalence between vector instr= uctions > and "tuning the GC". > You haven't said why they should be considered equivalent. >=20 > Nor have you said why you think C should not be allowed to use memory p= ools. 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 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > 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 >=20 --=20 ------------------------------------------------------------ Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany=20 gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ------------------------------------------------------------