caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jianzhou Zhao <jianzhou@seas.upenn.edu>
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Average cost of the OCaml GC
Date: Fri, 12 Nov 2010 12:27:40 -0500	[thread overview]
Message-ID: <AANLkTinepB+CydLrS5fPC4RzHikO5ANVkfDgQoaGk3_h@mail.gmail.com> (raw)
In-Reply-To: <8739r78vsq.fsf@frosties.localnet>

On Thu, Nov 11, 2010 at 3:11 PM, Goswin von Brederlow <goswin-v-b@web.de> wrote:
> Jianzhou Zhao <jianzhou@seas.upenn.edu> writes:
>
>> On Thu, Nov 11, 2010 at 4:08 AM, Goswin von Brederlow <goswin-v-b@web.de> wrote:
>>> Jianzhou Zhao <jianzhou@seas.upenn.edu> 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.

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
>        Goswin
>



-- 
Jianzhou


  reply	other threads:[~2010-11-12 17:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-11  3:59 Jianzhou Zhao
2010-11-11  9:08 ` [Caml-list] " Goswin von Brederlow
2010-11-11 13:52   ` Jianzhou Zhao
2010-11-11 14:14     ` Michael Ekstrand
2010-11-11 20:11     ` Goswin von Brederlow
2010-11-12 17:27       ` Jianzhou Zhao [this message]
2010-11-12 21:54         ` ygrek
2010-11-16 10:02         ` Goswin von Brederlow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTinepB+CydLrS5fPC4RzHikO5ANVkfDgQoaGk3_h@mail.gmail.com \
    --to=jianzhou@seas.upenn.edu \
    --cc=caml-list@yquem.inria.fr \
    --cc=goswin-v-b@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).