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 25086BBAF for ; Fri, 12 Nov 2010 18:27:43 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkCALMH3UzRVdc0kGdsb2JhbACUK44iCBUBAQEBCQkMBxEDH6Qzi3iFKyOIZAEBAwWFRQSEWoV9iSo X-IronPort-AV: E=Sophos;i="4.59,188,1288566000"; d="scan'208";a="77776677" Received: from mail-ew0-f52.google.com ([209.85.215.52]) by mail4-smtp-sop.national.inria.fr with ESMTP; 12 Nov 2010 18:27:42 +0100 Received: by ewy4 with SMTP id 4so201479ewy.39 for ; Fri, 12 Nov 2010 09:27:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=AsRhCt/NaN3cPAUFCnVB0t2UtWiKv0C7nW2jZQH0RuE=; b=KWBnkc3JPFN6DCL4xZH2nhBCEPoMbxKF+TMnOhw8kGWx7ACkVpPuQSrMcpghnqjJ2L gz2Jlu6wPJuNLg1CQyaYdaiRh/IXbfpkPzT3aGfMgpeRUGZcaIJovxDD2rUb5Cs1W7SJ wgqI8pBUhFBH375ORKJ/V6vE0EPWHNksss8XU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=pBZGCAOGkDrmOY0gISWCyxv8AvK/APzvqxXVvbX2f0kZwCdheJrtClu/MTnHNYQp0f u1QJPFOjuYuv6+Y7AJwd+WIIR/BnbepuBtiOq9mTYhVANV/fVDulH6XocmzxE2grzy0J Ek0Va284yrPjADm9gUu6JblpjtXeLtWWYkRx0= MIME-Version: 1.0 Received: by 10.216.188.71 with SMTP id z49mr2205022wem.82.1289582861031; Fri, 12 Nov 2010 09:27:41 -0800 (PST) Sender: jianzhou.zh@gmail.com Received: by 10.216.239.132 with HTTP; Fri, 12 Nov 2010 09:27:40 -0800 (PST) In-Reply-To: <8739r78vsq.fsf@frosties.localnet> References: <87bp5w1b47.fsf@frosties.localnet> <8739r78vsq.fsf@frosties.localnet> Date: Fri, 12 Nov 2010 12:27:40 -0500 X-Google-Sender-Auth: ZRkwpkOGxDVCK-LYf9xGhwIpUdw Message-ID: Subject: Re: [Caml-list] Average cost of the OCaml GC From: Jianzhou Zhao To: Goswin von Brederlow Cc: caml-list@yquem.inria.fr Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 wrote:01 On Thu, Nov 11, 2010 at 3:11 PM, Goswin von Brederlow w= rote: > 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' =A0and =A0'sweep_slice' =A0are functions from OCaml GC. A= re >>>> 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 >> =A0 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 >> =3D 0 and max =3D 1. But if you later find that the finalization functio= ns >> are not called =93often enough=94, 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 =3D 1000000 would be wrong here. Your 0/1 setting look fine to me. Do we still have other methods to debug such problems? Is it possible to know when and where GC runs, say, the number of times GC works after a particular usr-defined function? If this is possible, I was wondering if we can see which function in my code behave wrong. > > MfG > =A0 =A0 =A0 =A0Goswin > --=20 Jianzhou