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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 78D45BBAF for ; Mon, 22 Nov 2010 17:00:14 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8CABIi6kzZSMDqgmdsb2JhbACiXRUBAQsLCAcTAx+IK7R0hUsEjWyCbw X-IronPort-AV: E=Sophos;i="4.59,236,1288566000"; d="scan'208";a="80706056" Received: from fmmailgate03.web.de ([217.72.192.234]) by mail2-smtp-roc.national.inria.fr with ESMTP; 22 Nov 2010 17:00:14 +0100 Received: from smtp01.web.de ( [172.20.0.243]) by fmmailgate03.web.de (Postfix) with ESMTP id 41815175C776B; Mon, 22 Nov 2010 16:55:00 +0100 (CET) Received: from [78.43.204.177] (helo=frosties.localdomain) by smtp01.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #24) id 1PKYjM-0005Vk-00; Mon, 22 Nov 2010 16:55:00 +0100 Received: from mrvn by frosties.localdomain with local (Exim 4.72) (envelope-from ) id 1PKYjL-0005mj-Pv; Mon, 22 Nov 2010 16:54:59 +0100 From: Goswin von Brederlow To: Edwin Cc: bluestorm , Gerd Stolpmann , caml-list@yquem.inria.fr Subject: Re: [Caml-list] Is OCaml fast? In-Reply-To: <20101122170146.185de46e@deb0> ("Edwin"'s message of "Mon, 22 Nov 2010 17:01:46 +0200") References: <1290434674.16005.354.camel@thinkpad> <20101122170146.185de46e@deb0> User-Agent: Gnus/5.110009 (No Gnus v0.9) XEmacs/21.4.22 (linux, no MULE) Date: Mon, 22 Nov 2010 16:54:59 +0100 Message-ID: <87zkt1ica4.fsf@frosties.localnet> 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/MHCZyaucoaY3lqDtCHvw1rOzYUapGp0kBkUMf yr4zODll7o0a0Q4ivsnJ1nnOt/A7C0mUIBV4d3QAsmt/z8QgCa Um4jXk26o= X-Spam: no; 0.00; ocaml:01 gerd:01 stolpmann:01 ocaml:01 edwin:98 mfg:98 wrote:01 wrote:01 compile:01 heap:01 heap:01 caml-list:01 minor:01 minor:01 writes:01 Török Edwin writes: > On Mon, 22 Nov 2010 15:36:30 +0100 > bluestorm wrote: > >> On Mon, Nov 22, 2010 at 3:04 PM, Gerd Stolpmann >> 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. > > Isn't it possible for the GC to realise its doing too many collections > and increase the minor heap size on its own? Maybe. The GC would have to see that with a larger minor heap it has sufficient space so that most values die before the collection. It could see that most values die after 1 major sweep and increasing the minor heap would likely keep them out of the major heap alltogether. > Or isn't it possible to determine at compile time an approximation for > a good heap size, and use that? Usualy that is dependent on the input. MfG Goswin