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 E3A5EBBAF for ; Mon, 22 Nov 2010 17:42:22 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkEAGMs6kxQW+UMgWdsb2JhbACUVY4IFQEBFiIivUqFSwSKXg X-IronPort-AV: E=Sophos;i="4.59,237,1288566000"; d="scan'208";a="67840519" Received: from lo.gmane.org ([80.91.229.12]) by mail3-smtp-sop.national.inria.fr with ESMTP; 22 Nov 2010 17:42:22 +0100 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PKZTA-0001fE-I6 for caml-list@inria.fr; Mon, 22 Nov 2010 17:42:20 +0100 Received: from avelizy-155-1-41-182.w83-204.abo.wanadoo.fr ([83.204.200.182]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Nov 2010 17:42:20 +0100 Received: from sylvain by avelizy-155-1-41-182.w83-204.abo.wanadoo.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Nov 2010 17:42:20 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Sylvain Le Gall Subject: Re: Optimizing garbage collection Date: Mon, 22 Nov 2010 16:42:04 +0000 (UTC) Message-ID: References: <4CE68FAB.6020102@elehack.net> <577267187.967802.1290367612809.JavaMail.root@zmbs1.inria.fr> X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: avelizy-155-1-41-182.w83-204.abo.wanadoo.fr User-Agent: slrn/pre1.0.0-18 (Linux) X-Spam: no; 0.00; le-gall:01 damien:01 damien:01 eray:01 ozkural:01 uniformly:01 cpuinfo:01 26,:98 doligez:01 doligez:01 garbage:01 wrote:01 wrote:01 heap:01 heap:01 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. Regards, Sylvain Le Gall