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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 77204BBAF for ; Mon, 22 Nov 2010 16:01:51 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYBAAIU6kzRVaE0kGdsb2JhbACDSp8HCBUBAQEBCQkMBxEDH4grmlCJJzyCGIR/LohZAQEDBYEdgzZzBI5Sggk X-IronPort-AV: E=Sophos;i="4.59,236,1288566000"; d="scan'208";a="89095300" Received: from mail-fx0-f52.google.com ([209.85.161.52]) by mail1-smtp-roc.national.inria.fr with ESMTP; 22 Nov 2010 16:01:51 +0100 Received: by fxm15 with SMTP id 15so4778224fxm.39 for ; Mon, 22 Nov 2010 07:01:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=J8p2YM4++E5NQVIUMmSIYBy6MJJ1F3+EHx90Cz0XWJ0=; b=a0yHjjv8osXxxSXVjTF9siWFZHUH2hQFHINEDiruBAlGMaVrFUw9b9q5DOVlPp5W21 Po0dwwArYlhtDaNkSEA5BbWyI+SetspYU+U+AgFh1QAutMRLYWKP1fxLSZgR1g8ucD5S 2dfQTVuwxQbq7E/2K+qf3Tca5a8TE6hvgWbNI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=Xrzbzssmzc0DJADPP9s75diGenr++F3ApFnZoupDcB0n7/oUqsrvtIEOmZpcnwgTd1 TRuUIXcAd69ZNLdPwrao/etqEHwcOGUbgLnVUeenY6LZeEJh0PONjqQnsbppUhHuu9Hx OwTjEHwywuGJzC8kUPusST+U2Cg+iyPMfdGQM= Received: by 10.223.108.147 with SMTP id f19mr3765995fap.68.1290438110727; Mon, 22 Nov 2010 07:01:50 -0800 (PST) Received: from deb0 ([79.114.95.139]) by mx.google.com with ESMTPS id a25sm1367730fab.13.2010.11.22.07.01.49 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Nov 2010 07:01:50 -0800 (PST) Date: Mon, 22 Nov 2010 17:01:46 +0200 From: =?UTF-8?B?VMO2csO2aw==?= Edwin To: bluestorm Cc: Gerd Stolpmann , caml-list@yquem.inria.fr Subject: Re: [Caml-list] Is OCaml fast? Message-ID: <20101122170146.185de46e@deb0> In-Reply-To: References: <1290434674.16005.354.camel@thinkpad> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; ocaml:01 gerd:01 stolpmann:01 ocaml:01 edwin:98 wrote:01 wrote:01 compile:01 heap:01 heap:01 caml-list:01 minor:01 measurements:01 arbitrary:02 arbitrary:02 On Mon, 22 Nov 2010 15:36:30 +0100 bluestorm wrote: > On Mon, Nov 22, 2010 at 3:04 PM, Gerd Stolpmann > wrote: >=20 > > 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? > > >=20 > 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. >=20 > http://shootout.alioth.debian.org/u32/performance.php?test=3Dbinarytrees >=20 > =C2=AB 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. =C2=BB > C version : 12.11 secs > OCaml version : 47.22 secs > OCaml version with GC parameters tuned ("interesting alternative" > section) : 12.67 secs >=20 >=20 > 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? Or isn't it possible to determine at compile time an approximation for a good heap size, and use that? Best regards, --Edwin