Version française
Home     About     Download     Resources     Contact us    
Browse thread
Average cost of the OCaml GC
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Goswin von Brederlow <goswin-v-b@w...>
Subject: Re: [Caml-list] Average cost of the OCaml GC
Jianzhou Zhao <jianzhou@seas.upenn.edu> writes:

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

Only the interface the GC module exposes. You can turn the GC quite
verbose.

MfG
        Goswin