Browse thread
Average cost of the OCaml GC
-
Jianzhou Zhao
-
Goswin von Brederlow
-
Jianzhou Zhao
- Michael Ekstrand
- Goswin von Brederlow
-
Jianzhou Zhao
-
Goswin von Brederlow
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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 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.
MfG
Goswin