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 5AB54BBAF for ; Wed, 24 Nov 2010 23:29:58 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuoCAEIg7UzZSMDqgmdsb2JhbACjCRUBAQsLCAcTAx+IK7YXhUcEjW8 X-IronPort-AV: E=Sophos;i="4.59,250,1288566000"; d="scan'208";a="80152835" Received: from fmmailgate03.web.de ([217.72.192.234]) by mail4-smtp-sop.national.inria.fr with ESMTP; 24 Nov 2010 23:29:58 +0100 Received: from smtp07.web.de ( [172.20.5.215]) by fmmailgate03.web.de (Postfix) with ESMTP id 7B74C1775D4C9; Wed, 24 Nov 2010 23:28:12 +0100 (CET) Received: from [78.43.204.177] (helo=frosties.localdomain) by smtp07.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #24) id 1PLNoy-0001Vq-00; Wed, 24 Nov 2010 23:28:12 +0100 Received: from mrvn by frosties.localdomain with local (Exim 4.72) (envelope-from ) id 1PLNoy-0005U2-0C; Wed, 24 Nov 2010 23:28:12 +0100 From: Goswin von Brederlow To: Gerd Stolpmann Cc: Isaac Gouy , caml-list@inria.fr Subject: Re: [Caml-list] Re: Is OCaml fast? References: <1290434674.16005.354.camel@thinkpad> <20101123.113733.2059974256209184038.Christophe.Troestler+ocaml@umons.ac.be> <1290540286.16005.411.camel@thinkpad> Date: Wed, 24 Nov 2010 23:28:11 +0100 In-Reply-To: <1290540286.16005.411.camel@thinkpad> (Gerd Stolpmann's message of "Tue, 23 Nov 2010 20:24:46 +0100") Message-ID: <87vd3mpdac.fsf@frosties.localnet> User-Agent: Gnus/5.110009 (No Gnus v0.9) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: goswin-v-b@web.de X-Sender: goswin-v-b@web.de X-Provags-ID: V01U2FsdGVkX1/twUqEcQ5ShYtYmUDmgpVJJD5Li5ti98ErvoDB t1536vRtobM1J4COHe9ETOOJN+9X2dUUwJ/jiDD07QK7A4r4it M1grSG5KQ= X-Spam: no; 0.00; ocaml:01 gerd:01 stolpmann:01 christophe:01 troestler:01 christophe:01 troestler:01 ocaml:01 gerd:01 bigarray:01 dienstag:98 tor:98 innocent:98 mfg:98 wrote:01 Gerd Stolpmann writes: > Am Dienstag, den 23.11.2010, 17:53 +0000 schrieb Isaac Gouy: >> Christophe TROESTLER 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 So write an ocaml programm that uses and array or bigarray to pool its memory. That is the same as C does. MfG Goswin