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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id C11D6BBAF for ; Mon, 22 Nov 2010 19:07:11 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEBAE9A6kxKfVM2kGdsb2JhbACUKIYpAYgHCBUBAQEBCQkMBxEDH6M2iWOCGIUpLohZAQEDBYVGBIpe X-IronPort-AV: E=Sophos;i="4.59,237,1288566000"; d="scan'208";a="67846432" Received: from mail-gw0-f54.google.com ([74.125.83.54]) by mail3-smtp-sop.national.inria.fr with ESMTP; 22 Nov 2010 19:07:11 +0100 Received: by gwj20 with SMTP id 20so4537504gwj.27 for ; Mon, 22 Nov 2010 10:07:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=++Wg3W8maN6jiHnRTpM8WQhyH6ybqIeZyTUMNNRsBks=; b=m4C4+x7g8IyWhOViwBnAGgwVWKxp7q6CTaaRGwTko8mf8aPocaiOgFJfrrPLzooHWD BCAK0zy8E/aCn9Nfm32XFhvYq+IOatOqpoSu2xx7pbsSx83D5e/T75j38cZStlNm6Cf6 M08qqAHbPDgAys90fhFsKlm89lF8dfymAH/jw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SDZeKn2y+0y2fKcIca6CsACWu4DuFXaY/9/TCGxKyLnD0hmAk96J/4hc7geDBCUP1B 9mr7xI6DPoRGeLXPSwNHm1/7PJ99NUPF4PU+2aroxZzZW4I/tP9N2os0BqWbinAfhf4Q QJYr92AbsSdMBGAqokStFc4K8K4pWmC1p+2XU= MIME-Version: 1.0 Received: by 10.90.1.34 with SMTP id 34mr6200543aga.59.1290449229647; Mon, 22 Nov 2010 10:07:09 -0800 (PST) Received: by 10.91.154.3 with HTTP; Mon, 22 Nov 2010 10:07:09 -0800 (PST) In-Reply-To: References: <4CE68FAB.6020102@elehack.net> <577267187.967802.1290367612809.JavaMail.root@zmbs1.inria.fr> Date: Mon, 22 Nov 2010 20:07:09 +0200 Message-ID: Subject: Re: [Caml-list] Re: Optimizing garbage collection From: Eray Ozkural To: Sylvain Le Gall Cc: caml-list@inria.fr Content-Type: multipart/alternative; boundary=00163630fff3ef0e330495a81fb2 X-Spam: no; 0.00; eray:01 ozkural:01 le-gall:01 damien:01 damien:01 eray:01 ozkural:01 uniformly:01 cpuinfo:01 amortize:01 bilkent:01 le-gall:01 uniformly:01 cpuinfo:01 amortize:01 --00163630fff3ef0e330495a81fb2 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 22, 2010 at 6:42 PM, Sylvain Le Gall wrote: > On 22-11-2010, Damien Doligez wrote: > > > > On 2010-11-21, at 20:26, Eray Ozkural wrote: > > > >> I've been thinking whether some kind of doubling strategy would work for > the minor heap size. What do you think? > > > > Sounds like an interesting idea, but what heuristic would you use? > > When everything is smooth, the running time decreases something like > > exponentially with the minor heap size, so you'd always want to > > increase the size. How do you tell when to stop? And then, if the > > program is not behaving uniformly, when do you decide to reduce > > the size? > > > > How do you tell when to stop? > -> > > Maybe you can stop when you reach (the size of the L2/L3 cache of the > processor) / number of core. > > Both information are quite straight to read from /proc/cpuinfo. > Yeah that's what I had in mind, determine a kind of sensible upper bound to grow to. Cache size makes some sense, though I think as recently mentioned "working set size" is relevant. If the garbage collector could deduce that it could be used, the other suggestion is also sensible. You could also set it to something like 1/4 of physical RAM. That kind of logic is used in some out-of-core data mining algorithms. The objective here is to amortize the cost of copying until the working set size is reached, otherwise there will be disk thrashing anyway! Best, -- Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara http://groups.yahoo.com/group/ai-philosophy http://myspace.com/arizanesil http://myspace.com/malfunct --00163630fff3ef0e330495a81fb2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Nov 22, 2010 at 6:42 PM, Sylvain Le Gall <sylvain@le-gall.net> wrote= :
On 22-11-2010, Damien Doligez <damien.doligez@inria.fr> wrote:
>
> On 2010-11-21, at 20:26, Eray Ozkural wrote:
>
>> I've been thinking whether some kind of doubling strategy woul= d work for the minor heap size. What do you think?
>
> Sounds like an interesting idea, but what heuristic would you use?
> When everything is smooth, the running time decreases something like > exponentially with the minor heap size, so you'd always want to > increase the size. =A0How do you tell when to stop? =A0And then, if th= e
> program is not behaving uniformly, when do you decide to reduce
> the size?
>

How do you tell when to stop?
->

Maybe you can stop when you reach (the size of the L2/L3 cache of the
processor) / number of core.

Both information are quite straight to read from /proc/cpuinfo.
=A0

Yeah that's what I had in mind, determine a= kind of sensible upper bound to grow to. Cache size makes some sense, thou= gh I think as recently mentioned "working set size" is relevant. = If the garbage collector could deduce that it could be used, the other sugg= estion is also sensible. You could also set it to something like 1/4 of phy= sical RAM. That kind of logic is used in some out-of-core data mining algor= ithms.

The objective here is to amortize the cost of copying u= ntil the working set size is reached, otherwise there will be disk thrashin= g anyway!=A0

Best,
=A0
-- Eray Ozkural, PhD candidate.=A0 Comp. Sci. Dept., Bilkent University, Ankar= a
http://groups.= yahoo.com/group/ai-philosophy
http://myspace.com/arizanesil http://myspace.com/malfunct

--00163630fff3ef0e330495a81fb2--