Re: [Caml-list] Optimizing garbage collection

Re: [Caml-list] Optimizing garbage collection

[Damien Doligez]

On 2010-11-22, at 19:38, John Carr wrote:

> I don't understand "smooth".  Minor heap size should be based on the
> rate of garbage generation relative to allocation to balance cache
> misses with GC cost.  The ratio may be small or large independent of
> whether it varies during the program.


What I meant is that, if the allocation rate of the program is infinitely
regular and you don't get any threshold effects, the running time decreases
as the minor heap size increases, and it's hard to tell when you should
stop increasing it.

For benchmarks the best choice is probably the physical memory size, but
you certainly don't want your real programs to do that.

-- Damien

Re: [Caml-list] Optimizing garbage collection

[Christophe Raffalli]

[-- Attachment #1.1: Type: text/plain, Size: 1092 bytes --]


Hello,

May be running a minimisation algorithm to minimize (promoted_words per
minor collection / minor_heap_size)  Could be good ?

If we retain the value of this ration for the last N minor_collection,
we can surely guess
a good value for the next cycle (using trichomomy for instance) ...

I will have a look if nobody elso does before me.

Unfortunately to write this in OCaml itself is not so easy: there are no
alarm for minor collection cycle, so will only get values for major
cycle or via a timer with fixed intervals ...

Cheers,
Christophe


-- 
Christophe Raffalli
Universite de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tel: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution 
can check this signature. The public key is
stored on www.keyserver.net
---------------------------------------------


[-- Attachment #1.2: Christophe_Raffalli.vcf --]
[-- Type: text/x-vcard, Size: 310 bytes --]

begin:vcard
fn:Christophe Raffalli
n:Raffalli;Christophe
org:LAMA (UMR 5127)
email;internet:christophe.raffalli@univ-savoie.fr
title;quoted-printable:Ma=C3=AEtre de conf=C3=A9rences
tel;work:+33 4 79 75 81 03
note:http://www.lama.univ-savoie.fr/~raffalli
x-mozilla-html:TRUE
version:2.1
end:vcard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Caml-list] Optimizing garbage collection

[Christophe Raffalli]

[-- Attachment #1: Type: text/plain, Size: 2374 bytes --]

Le 23/11/2010 14:40, Christophe Raffalli a écrit :
> 
> Hello,
> 
> May be running a minimisation algorithm to minimize (promoted_words per
> minor collection / minor_heap_size)  Could be good ?
> 

This was stupid has it converges toward zero when we increase minor_heap_size.

However, the following piece of code worked well for PML benchmark (4'30" became 3'02") :
(remark that HALVING the minor_heap_size does occur too)

I really do not know if such strategy is reasonnable as a default ?
If the 0.10 and 0.005 in the code are any reasonnable ?

-------------------8<---------------------
open Gc

let param = get ()

let old_promoted_words = ref 0.0
let old_minor_collections = ref 0
let minor_heap_size = ref param.minor_heap_size

let _ = create_alarm (fun () ->
  let s = quick_stat () in
  let promoted_words = s.promoted_words in
  let minor_collections = s.minor_collections in
  let delta_promoted_words = promoted_words -. !old_promoted_words in
  let delta_minor_collections = minor_collections - !old_minor_collections in
  old_promoted_words := promoted_words;
  old_minor_collections := minor_collections;
  let ratio = delta_promoted_words /. (float) delta_minor_collections
                                   /. (float) !minor_heap_size
  in
  if ratio > 0.10 then begin
    minor_heap_size := !minor_heap_size * 2;
(*  Printf.fprintf stderr "MHS DOUBLED <- %d (ratio %f)\n" !minor_heap_size ratio;
    flush stderr; *)
    set { get () with minor_heap_size = !minor_heap_size }
  end else if ratio < 0.005 then begin
    minor_heap_size := max 32768 (!minor_heap_size / 2);
(*  Printf.fprintf stderr "MHS HALFED <- %d (ratio %f)\n" !minor_heap_size ratio;
    flush stderr; *)
    set { get () with minor_heap_size = !minor_heap_size }
  end)
-------------------8<---------------------

-- 
Christophe Raffalli
Universite de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tel: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature. The public key is
stored on www.keyserver.net
---------------------------------------------


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [Caml-list] Optimizing garbage collection

[John Carr]

> When everything is smooth, the running time decreases something like
> exponentially with the minor heap size, so you'd always want to
> increase the size.  How do you tell when to stop?  And then, if the
> program is not behaving uniformly, when do you decide to reduce
> the size?

I don't understand "smooth".  Minor heap size should be based on the
rate of garbage generation relative to allocation to balance cache
misses with GC cost.  The ratio may be small or large independent of
whether it varies during the program.

The default minor heap size is well tuned for traditional functional
programming behavior: high rate of allocation, short lifetime.

When memory access is smaller than a cache line the cache does not
reward data reuse so much as address reuse.  Collecting a small minor
heap that is mostly garbage allows the allocator to start over at
an address that is already in cache.  Continuing to allocate instead
of collecting leads to write-allocate misses.

Re: [Caml-list] Optimizing garbage collection

[Mauricio Fernandez]

On Mon, Nov 22, 2010 at 04:10:49PM +0100, Damien Doligez wrote:
> On 2010-11-21, at 20:26, Eray Ozkural wrote:
> 
> > I've been thinking whether some kind of doubling strategy would work for the minor heap size. What do you think?
> 
> Sounds like an interesting idea, but what heuristic would you use?
> When everything is smooth, the running time decreases something like
> exponentially with the minor heap size, so you'd always want to
> increase the size.  How do you tell when to stop?  And then, if the
> program is not behaving uniformly, when do you decide to reduce
> the size?

Just dropping an idea, not sure it's worth a dime...
How about an exponential growth scheme with hysteresis?
On each minor collection, multiply the size by a if the rate of promoted words
exceeds r1, divide by b if the rate is below r2 (r1 > r2); otherwise remain
stable.

In order to account for the effect of the cache hierarchy, r1 and r2 could
also be a function of the current heap size (e.g., with r1 and r2 being higher
when approaching "magic" numbers such as the size of the L2 cache on the left
and right side respectively).

It'd also be very nice to be able to estimate the amount of time spent on
minor + major GC collection vs. the mutator.

-- 
Mauricio Fernandez  -   http://eigenclass.org

Re: [Caml-list] Optimizing garbage collection

[Damien Doligez]

On 2010-11-21, at 20:26, Eray Ozkural wrote:

> I've been thinking whether some kind of doubling strategy would work for the minor heap size. What do you think?

Sounds like an interesting idea, but what heuristic would you use?
When everything is smooth, the running time decreases something like
exponentially with the minor heap size, so you'd always want to
increase the size.  How do you tell when to stop?  And then, if the
program is not behaving uniformly, when do you decide to reduce
the size?

-- Damien

Re: [Caml-list] Optimizing garbage collection

[Eray Ozkural]

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]

Hello there Alexandre,

On Sun, Nov 21, 2010 at 8:13 PM, Alexandre Pilkiewicz <
alexandre.pilkiewicz@polytechnique.org> wrote:

> Hi
>
> 2010/11/20 Eray Ozkural <examachine@gmail.com>:
> > Yes, the default minor heap size was indeed too low, I've been trying to
> set
> > it to a higher value, now testing with the OCAMLRUNPARAM settings you
> > recommended. It did result in some speedup, but not an awful lot, it's
> > important to profile it as you say.
>
> Can you tell us how high you set it? I would recommend at least
> 524288, and even something like 3000000 if you really need to (I'm
> talking in words here)
>

I've set it to 4M and I think it's worked wonders, the collection time is no
more so significant in gprof output (surprisingly) at least now I can
identify the real bottlenecks! Indeed the 5-instr long fast path is quite
fast. Due to the peculiarities of my code, it didn't result in much speedup
but I've solved this problem, I can't believe I've overlooked the Gc
parameters, I should probably be setting them from within the code. A bit
embarrassed about it actually :)

I've been thinking whether some kind of doubling strategy would work for the
minor heap size. What do you think?

Best,

-- 
Eray Ozkural, PhD candidate.  Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/ai-philosophy
http://myspace.com/arizanesil http://myspace.com/malfunct

[-- Attachment #2: Type: text/html, Size: 2052 bytes --]

Re: [Caml-list] Optimizing garbage collection

[Alexandre Pilkiewicz]

Hi

2010/11/20 Eray Ozkural <examachine@gmail.com>:
> Yes, the default minor heap size was indeed too low, I've been trying to set
> it to a higher value, now testing with the OCAMLRUNPARAM settings you
> recommended. It did result in some speedup, but not an awful lot, it's
> important to profile it as you say.

Can you tell us how high you set it? I would recommend at least
524288, and even something like 3000000 if you really need to (I'm
talking in words here).

Cheers

Alexandre

Re: [Caml-list] Optimizing garbage collection

[Eray Ozkural]

[-- Attachment #1: Type: text/plain, Size: 2846 bytes --]

The program I am testing it on is basically a DFS algorithm so it doesn't
use much heap memory really. Just a lot of transient objects.

Looking at the top the RSIZE looks to be not over 11M under OSX.

Yes, the default minor heap size was indeed too low, I've been trying to set
it to a higher value, now testing with the OCAMLRUNPARAM settings you
recommended. It did result in some speedup, but not an awful lot, it's
important to profile it as you say.

Best,

On Fri, Nov 19, 2010 at 4:54 PM, Michael Ekstrand <michael@elehack.net>wrote:

> On 11/18/2010 09:51 AM, Eray Ozkural wrote:
> > A program I wrote constructs a lot of small lists, and strings and
> > discards them. It's a search algorithm. I profiled this code and saw
> > that garbage collection takes significant time.
> >
> > In C++, we can write custom allocators to optimize the data structures
> > that cause such slowdowns. Any recommended strategies in ocaml?
>
> The OCaml garbage collector exposes a variety of tuning parameters
> through the Gc module[1] and the OCAMLRUNPARAM environment variable[2].
>  I would tweak those.  In particular, I would recommend increasing the
> minor heap size so that more of your data can be quickly discarded.  You
> can also increase the space overhead, thereby causing the GC to be less
> aggressive at the expense of higher memory usage/more waste.  Lastly, I
> often increase the heap increment to allow memory to allow the heap to
> expand more quickly, but I do not know if that will help in your case or
> not.  I have documented my practices more thoroughly at my blog[3].
>
> As I see it, the biggest gains will be by tuning your code and your
> minor heap size so that ephemeral structures never hit the major heap.
> My rule of thumb is that one "work unit", if you have such a concept,
> should fit in the minor heap.  Collecting dead structures from the minor
> heap is fast; moving a structure to the major heap only to have it be
> unreachable by the next GC cycle can cause substantial GC thrashing.
>
> You're on to a good start, though, by measuring.  I use gprof heavily as
> I tweak my code's performance.
>
> - Michael
>
> 1. http://caml.inria.fr/pub/docs/manual-ocaml/libref/Gc.html
> 2. http://caml.inria.fr/pub/docs/manual-ocaml/manual024.html#toc96
> 3. http://elehack.net/michael/blog/2010/06/ocaml-memory-tuning
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>



-- 
Eray Ozkural, PhD candidate.  Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/ai-philosophy
http://myspace.com/arizanesil http://myspace.com/malfunct

[-- Attachment #2: Type: text/html, Size: 4108 bytes --]

Re: [Caml-list] Optimizing garbage collection

[Eray Ozkural]

[-- Attachment #1: Type: text/plain, Size: 249 bytes --]

Thanks a lot for the suggestions Michael. Much appreciated.

Best,

-- 
Eray Ozkural, PhD candidate.  Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/ai-philosophy
http://myspace.com/arizanesil http://myspace.com/malfunct

[-- Attachment #2: Type: text/html, Size: 457 bytes --]

Re: [Caml-list] Optimizing garbage collection

[Michael Ekstrand]

On 11/18/2010 09:51 AM, Eray Ozkural wrote:
> A program I wrote constructs a lot of small lists, and strings and
> discards them. It's a search algorithm. I profiled this code and saw
> that garbage collection takes significant time.
> 
> In C++, we can write custom allocators to optimize the data structures
> that cause such slowdowns. Any recommended strategies in ocaml?

The OCaml garbage collector exposes a variety of tuning parameters
through the Gc module[1] and the OCAMLRUNPARAM environment variable[2].
 I would tweak those.  In particular, I would recommend increasing the
minor heap size so that more of your data can be quickly discarded.  You
can also increase the space overhead, thereby causing the GC to be less
aggressive at the expense of higher memory usage/more waste.  Lastly, I
often increase the heap increment to allow memory to allow the heap to
expand more quickly, but I do not know if that will help in your case or
not.  I have documented my practices more thoroughly at my blog[3].

As I see it, the biggest gains will be by tuning your code and your
minor heap size so that ephemeral structures never hit the major heap.
My rule of thumb is that one "work unit", if you have such a concept,
should fit in the minor heap.  Collecting dead structures from the minor
heap is fast; moving a structure to the major heap only to have it be
unreachable by the next GC cycle can cause substantial GC thrashing.

You're on to a good start, though, by measuring.  I use gprof heavily as
I tweak my code's performance.

- Michael

1. http://caml.inria.fr/pub/docs/manual-ocaml/libref/Gc.html
2. http://caml.inria.fr/pub/docs/manual-ocaml/manual024.html#toc96
3. http://elehack.net/michael/blog/2010/06/ocaml-memory-tuning