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 6692CBBAF for ; Sat, 27 Nov 2010 16:59:07 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwBABS68ExKfVK2kGdsb2JhbACjBggVAQEBAQkJDAcRAx+laYlkghiEMy6IVgEBAwWFQgSOVw X-IronPort-AV: E=Sophos;i="4.59,266,1288566000"; d="asc'?scan'208";a="89488105" Received: from mail-wy0-f182.google.com ([74.125.82.182]) by mail1-smtp-roc.national.inria.fr with ESMTP; 27 Nov 2010 16:59:07 +0100 Received: by wyf19 with SMTP id 19so18473676wyf.27 for ; Sat, 27 Nov 2010 07:59:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=Sd1ub4inShT27HmSazbJsjKeW6vf+MrI3GrYHFMcVUI=; b=bQf6anBw7cHGsrpQIr4ql4OWUWkmN8QJMevAwLGMeW6wXzWM6YcelDtrtYWLhT+QYZ GyZIslVko2bWhwtLkPGaLO15vKeRkOXK9cG4ar8DdJFZLjbtCwaGpuhrOlorOGLkHMhh SQAAuxNsIQTvAtFQMdj8QXtrkLj6zyoQHQW0w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; b=xtTvVx9NfldVBGGBJEYgaFw7SVqBpEzG6UFpS5dHnDz/7XqWgdv1EwiAOlSBx5aafY PG6lVEKn486IfdbS9cqNuhRQfNwSKuLD5s/WiOGHy514TL4a5d9g6ip2fEOC8nFwls9Z kPTC08QtNAzZB3XF0Ahf+l4EjVixNrLoe5QeM= Received: by 10.227.146.149 with SMTP id h21mr3776654wbv.139.1290873546570; Sat, 27 Nov 2010 07:59:06 -0800 (PST) Received: from macbookpro.local (vpn-b-advanced.univ-savoie.fr [193.48.127.14]) by mx.google.com with ESMTPS id 11sm2131551wbi.18.2010.11.27.07.59.03 (version=SSLv3 cipher=RC4-MD5); Sat, 27 Nov 2010 07:59:04 -0800 (PST) Message-ID: <4CF12ABF.7010803@univ-savoie.fr> Date: Sat, 27 Nov 2010 16:58:55 +0100 From: Christophe Raffalli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Stefan Monnier , OCaml Subject: Re: [Caml-list] Re: Is OCaml fast? References: <1290434674.16005.354.camel@thinkpad> <20101122180203.2126497sau3zukgb@webmail.in-berlin.de> <20101123232742.GC28768@siouxsie> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5915072CAD335227A092A8D1" X-Spam: no; 0.00; christophe:01 raffalli:01 ocaml:01 ocaml's:01 ocaml:01 bool:01 runtime:01 generations:01 cheers:01 christophe:01 garbage:01 heap:01 heap:01 caml-list:01 minor:01 X-Attachments: type="application/pgp-signature" name="signature.asc" name="signature.asc" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5915072CAD335227A092A8D1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, > To the extent that this rule is the same for all languages and that mos= t > languages on the shootout are also garbage collected, I think OCaml's > problem with this benchmark do point at a weakness of the current > GC code. This is untrue ... the bintree example, is just bad in OCaml because the default value of the minor heap size is the correct value for reactive programs where you want fast minor GC slice, because they interrupt the program ..= =2E Maybe the Gc library could provide reasonable default settings for both cases accessible via a simple function GC.is_reactive : bool -> unit ... And the shootout would allow to call such a function ? Clearly, all benchmarks which just measure speed and space should use a larger minor heap size (except if reactive communication between processes is important in the benchmark). More importantly, there is little hope to discover at runtime that a program is a reactive one ... In other words there is no hope for a perfect GC for all situations. So it is a good thing that OCaml allows tuning the GC. Moreover, even when you automatically tune the GC (like changing the number of generations in some modern GC) you do it based on past observation of the behavior of your program ... and the behavior of the program can change just after you changed some GC parameters ... So begin able to help the GC, in a comprehensive way, is good ... Cheers, Christophe --------------enig5915072CAD335227A092A8D1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzxKsQACgkQi9jr/RgYAS52WgCfbPECyhjgDnnsukuCyBXMI1U1 +roAmwbm02kbtmtFut6JhDQytlDEMBi9 =Fy2Z -----END PGP SIGNATURE----- --------------enig5915072CAD335227A092A8D1--