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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 13751BC57 for ; Mon, 29 Nov 2010 23:27:40 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMBAL+380zRVaE0kGdsb2JhbACVAI4DCBUBAQEBCQkMBxEDH4gsn1iJZIIYhSguiFYBAQMFgn8IgjsEjlc X-IronPort-AV: E=Sophos;i="4.59,277,1288566000"; d="scan'208";a="80673924" Received: from mail-fx0-f52.google.com ([209.85.161.52]) by mail4-smtp-sop.national.inria.fr with ESMTP; 29 Nov 2010 23:27:39 +0100 Received: by fxm5 with SMTP id 5so3854003fxm.39 for ; Mon, 29 Nov 2010 14:27:39 -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:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=vY1RGh9GgULyUF1rPXKsqAA1VYYMNV7/JzeXLv2uZF8=; b=HIC3qrx9qaue3U3ONEdnnKXiKXJeEmTqXkqIOHNBZ0pRHikimGHeJy5YSvO0aZGSAD PrDaUZozg/xsg6XEKBkFMY5Wn9yXHg2imECYFEUoVXvPajXaslL8VZfCW2jxtZZxbD6d LBx69kDlvBvK9IrG6qgjY5aLMKFlpI5B+pWMw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=a2tD9iA/7rPGZfovET9ONUvlOKzihB7Isb7ffhxT+qeCeyw83EQlntX1tWokdHvFF+ Ncc1HNVVhATmVFNZmow5+Sz200+Hj1fqgoiNcZ9wIQmLC9O2sjkyb5pvmAOMqwodY/Tz 3SJIM9K5KmjXoitvVocuWlLA9oDEVo9IRFaAI= Received: by 10.223.87.3 with SMTP id u3mr6011462fal.131.1291069658345; Mon, 29 Nov 2010 14:27:38 -0800 (PST) Received: from deb0 ([79.114.81.178]) by mx.google.com with ESMTPS id c10sm1418687fat.30.2010.11.29.14.27.37 (version=SSLv3 cipher=RC4-MD5); Mon, 29 Nov 2010 14:27:37 -0800 (PST) Date: Tue, 30 Nov 2010 00:27:27 +0200 From: =?UTF-8?B?VMO2csO2aw==?= Edwin To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] OCaml GC [was Is OCaml fast?] Message-ID: <20101130002727.252a19ab@deb0> In-Reply-To: References: <1290434674.16005.354.camel@thinkpad> <582306206.731582.1290438133628.JavaMail.root@zmbs4.inria.fr> <20101122203334.7adc5ee6@deb0> <20101127221121.0920db65@ordinaves.concept-micro.com> <4CF25878.4060202@univ-savoie.fr> 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=US-ASCII Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; ocaml:01 ocaml:01 generational:01 ocaml's:01 wsize:01 bsize:01 ocaml's:01 edwin:98 3.0:98 2.0:98 wrote:01 heap:01 heap:01 caml-list:01 minor:01 On Sun, 28 Nov 2010 15:29:08 +0100 Benedikt Meurer wrote: > Speaking of the OCaml GC in general, wouldn't it make sense to > replace the current generational collector with a collector framework > that requires less copying in the common case. Even without changing the GC algorithm, I think it would be useful if we could minimize the amount of "useless work" major collections do in the current GC. I profiled the binary trees with valgrind's callgrind, and it turns out that most of the time for each minor collection is spent in caml_major_collection_slice: http://www.pasteall.org/pic/show.php?id=7194 This seems to be in concordance with the "smaller minor heap => more minor collections => slower program" observation, since it is: smaller minor heap => more minor collections => more major slices => major slices can't collect long-lived objects => slower program (long lived objects are sweeped too many times). So more minor collections => higher cost for a major slice I think OCaml's GC should take into account how successful the last major GC was (how many words it freed), and adjust speed accordingly: if we know that the major slice will collect next to nothing there is no point in wasting time and running it. So this formula should probably be changed: p = (double) caml_allocated_words * 3.0 * (100 + caml_percent_free) / Wsize_bsize (caml_stat_heap_size) / caml_percent_free / 2.0; Probably to something that also does: p = p * major_slice_successrate where successrate is how many words the GC succeeded in collecting the last major slice (or last major collection). I'm not familiar with OCaml's GC, but it looks like it doesn't keep track of these stats during a collection, or does it? P.S.: It would be good if this internal speed percentage was tunable from the Gc module, at least by a constant factor. Best regards, --Edwin