From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <petchema@concept-micro.com>
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 95AF3BBAF
	for <caml-list@yquem.inria.fr>; Sat, 27 Nov 2010 22:11:34 +0100 (CET)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuoGACwD8UxeFy46X2dsb2JhbACDT5E9jgELHkivdo9ohFRzBIkshzU
X-IronPort-AV: E=Sophos;i="4.59,267,1288566000"; 
   d="asc'?scan'208";a="80326293"
Received: from ks369561.kimsufi.com ([94.23.46.58])
  by mail4-smtp-sop.national.inria.fr with ESMTP; 27 Nov 2010 22:11:32 +0100
Received: from ordinaves.concept-micro.com (ABordeaux-157-1-35-254.w90-30.abo.wanadoo.fr [90.30.130.254])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: petchema)
	by ks369561.kimsufi.com (Postfix) with ESMTPSA id 02147755A1
	for <caml-list@yquem.inria.fr>; Sat, 27 Nov 2010 22:11:31 +0100 (CET)
Date: Sat, 27 Nov 2010 22:11:21 +0100
From: Pierre =?UTF-8?B?RXRjaGVtYcOvdMOp?= <petchema@concept-micro.com>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Is OCaml fast?
Message-ID: <20101127221121.0920db65@ordinaves.concept-micro.com>
In-Reply-To: <20101122203334.7adc5ee6@deb0>
References: <AANLkTi=MFt3mGK2L_o=4=o=3FOtA2onvdvqTpw9SObYP@mail.gmail.com>
	<1290434674.16005.354.camel@thinkpad>
	<AANLkTi=nsgA3qEmpj0=89AodNN4M1tru+WJSsyYJ0ZqV@mail.gmail.com>
	<582306206.731582.1290438133628.JavaMail.root@zmbs4.inria.fr>
	<AANLkTinrvZRXzn5eFvyB2E4_CR_7+XU1zRtbNQLjMhVS@mail.gmail.com>
	<20101122203334.7adc5ee6@deb0>
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; x86_64-pc-linux-gnu)
X-Face: "1<D_YW=(Z@$kl':M7Gci`gAa"U.$bCElfWd@{578%xR_9MHE`RMTfG%f.dMf^xIS("~Dw$
 sCx~,%u0+T^YTq]o
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=PGP-SHA256;
 boundary="Sig_/9hBNyOde6KJ6_iTHlXgl5/."; protocol="application/pgp-signature"
X-Spam: no; 0.00; ocaml:01 0200,:01 compaction:01 edwin:98 garbage:01 heap:01 heap:01 caml-list:01 minor:01 minor:01 latency:01 latency:01 pierre:02 benchmark:04 guess:04 
X-Attachments: cset="UTF-8" type="application/pgp-signature" name="signature.asc" name="signature.asc" 

--Sig_/9hBNyOde6KJ6_iTHlXgl5/.
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Le Mon, 22 Nov 2010 20:33:34 +0200, T=C3=B6r=C3=B6k Edwin <edwintorok@gmail=
.com> a =C3=A9crit :

> Not sure what the max should be for the minor heap increase, but based
> on this benchmark increasing size of minor heap never slows down the
> program. Even when size of minor heap exceeds what fits in the cache.
> I guess there is another microbenchmark that can show the opposite
> though.

Another consequence of increasing minor heap size is the latency
introduced by minor heap collections. That said, when does it become
the worse garbage collector latency? (... when heap compaction is
disabled?)
And of course, for many programs such latency matters a lot less than
thoughput...

--Sig_/9hBNyOde6KJ6_iTHlXgl5/.
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iF4EAREIAAYFAkzxc/kACgkQDVFqWie1B6i3YAD/T2YB5dUkHK3RKGPxoiCZF5LM
T0qdbXcdR2RoSeZGE2EA/jXnbisYkoyWLPMb/32fiBxr373txbrnHvsVviJ6BuRj
=JEiz
-----END PGP SIGNATURE-----

--Sig_/9hBNyOde6KJ6_iTHlXgl5/.--