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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 8110BBBAF for ; Thu, 11 Nov 2010 21:38:18 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArACAPfi20zZSMDqe2dsb2JhbACiSBUBAQsLCgURBR/CZYVKBI1jiAo X-IronPort-AV: E=Sophos;i="4.59,184,1288566000"; d="scan'208";a="78419587" Received: from fmmailgate03.web.de ([217.72.192.234]) by mail2-smtp-roc.national.inria.fr with ESMTP; 11 Nov 2010 21:38:18 +0100 Received: from smtp02.web.de ( [172.20.0.184]) by fmmailgate03.web.de (Postfix) with ESMTP id 0845E1713DDE4; Thu, 11 Nov 2010 21:11:51 +0100 (CET) Received: from [78.43.204.177] (helo=frosties.localdomain) by smtp02.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #24) id 1PGdUs-0005VE-00; Thu, 11 Nov 2010 21:11:50 +0100 Received: from mrvn by frosties.localdomain with local (Exim 4.72) (envelope-from ) id 1PGdUs-0003yw-3c; Thu, 11 Nov 2010 21:11:50 +0100 From: Goswin von Brederlow To: Jianzhou Zhao Cc: Goswin von Brederlow , caml-list@yquem.inria.fr Subject: Re: [Caml-list] Average cost of the OCaml GC References: <87bp5w1b47.fsf@frosties.localnet> Date: Thu, 11 Nov 2010 21:11:49 +0100 In-Reply-To: (Jianzhou Zhao's message of "Thu, 11 Nov 2010 08:52:45 -0500") Message-ID: <8739r78vsq.fsf@frosties.localnet> User-Agent: Gnus/5.110009 (No Gnus v0.9) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: goswin-v-b@web.de X-Sender: goswin-v-b@web.de X-Provags-ID: V01U2FsdGVkX18Ss4qm1pQ72govnsjnY9BmyNlBk/1CnoStbHzi 68t9XEMUmFRhOW8XItVrFHFEujF1x/GDt3B0kfUrsTmnuRyiZh Aih+ZZtV4= X-Spam: no; 0.00; ocaml:01 ocaml:01 'self:01 'self:01 alloc:01 alloc:01 pointers:01 'as:01 zhao:98 zhao:98 57%:98 57%:98 mfg:98 wrote:01 upenn:01 Jianzhou Zhao writes: > On Thu, Nov 11, 2010 at 4:08 AM, Goswin von Brederlow wrote: >> Jianzhou Zhao writes: >> >>> Hi, >>> >>> What is the average cost of the OCaml GC? I have a program that calls >>> 'mark_slice' in 57% of the total execution time, and calls >>> 'sweep_slice' in 21% of the total time, reported by Callgrind, which >>> is a profiling tool in Valgrind. 57% and 21% are the 'self cost' --- >>> the cost of the function itself ('Self Cost'), rather than the cost >>> including all called functions ('Inclusive Cost'). I guess >>> 'mark_slice'  and  'sweep_slice'  are functions from OCaml GC. Are >>> these numbers normal? >> >> Those numbers sound rather high to me. >> >>> My program calls both OCaml and C, which passes around C data types in >>> between. I also doubt if I defined the interface in an 'unefficient' >>> way that slows down the GC. Are there any rules in mind to make GC >>> work more efficiently? >> >> You can tune some of the GC parameters to suit your use case. >> >> Do you allocate custom types from C? In caml_alloc_custom(ops, size, >> used, max) the used and max do influence the GC how often to run. > > Yes. The code uses caml_alloc_custom to create a lot of small objects > (less then 8 bytes) frequently. The used and max are set to be > default, 0 and 1. The manual says > http://caml.inria.fr/pub/docs/manual-ocaml/manual032.html#toc140 > > ///////////////////// > If your finalized blocks contain no pointers to out-of-heap resources, > or if the previous discussion made little sense to you, just take used > = 0 and max = 1. But if you later find that the finalization functions > are not called “often enough”, consider increasing the used / max > ratio. > ////////////////////// > > Does this mean the default used and max let GC do finalization 'as > slow as possible'? This does not seem to be the case if the costs 57% > and 20% are too high. I think 0/1 gives you the least amount of GC runs. >> If you set them wrong you might trigger the GC too often. > > In which case could they be set 'wrong'? For example, if 'used' is not > equal to the real amount of allocated data; or is there a range of > 'max' given a used? A used = 1000000 would be wrong here. Your 0/1 setting look fine to me. MfG Goswin