English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

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: 2010-11-16 (10:02)
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