how to "disable" GC?

how to "disable" GC?

[Eijiro Sumii]

Hello,

I'm trying some very unfair:-) comparisons between OCaml and MinCaml
(min-caml.sf.net), and wondering how to _disable_ GC in OCaml (on
SPARC).  I've tried

  setenv OCAMLRUNPARAM 's=1000000000,v=0x1ff'

and its variants, but none of them seem to stop GC from happening -
and once it happens, it's MUCH slower of course!  By the way, the
machine has 8GB main memory.

So, my questions are:

1. How does the GC happen at all when the minor heap is so huge?  The
   programs don't seem to use so much memory anyway...

2. Some programs get much slower for larger heaps, even though they
   don't seem to trigger any GC.  An example is such programs is given
   below.  Why is this?  (There also exist programs that are not
   affected at all, so this is not because of the initialization
   overhead of the runtime system.)

(**********************************************************************)
let rec tak x y z =
  if y >= x then z else
  tak (tak (x -. 1.0) y z) (tak (y -. 1.0) z x) (tak (z -. 1.0) x y) in
let n = 10.0 in
print_int (int_of_float (1000000.0 *. tak (n *. 3.0) (n *. 2.0) (n *. 1.0)));
print_newline ()
(**********************************************************************)

Thanks in advance,

--
Eijiro Sumii (http://www.cis.upenn.edu/~sumii/)
Department of Computer and Information Science, University of Pennsylvania

Re: [Caml-list] how to "disable" GC?

[Thomas Fischbacher]

On Sat, 12 Mar 2005, Eijiro Sumii wrote:

> 2. Some programs get much slower for larger heaps, even though they
>    don't seem to trigger any GC.  An example is such programs is given
>    below.  Why is this?  (There also exist programs that are not
>    affected at all, so this is not because of the initialization
>    overhead of the runtime system.)

Quite in general, Cache hierarchy may be an issue here. The CPU can only 
hold a small amount of data in its L1 cache, which is quite fast. Next, 
there are L2 and then L3 caches (should you have that), but if you have to 
do a lot of real memory access, that usually will kill you. Especially if 
your address space is so badly scrambled that the CPU constantly needs to 
re-load its address translation cache (called translation lookaside buffer 
for x86). Worst case situation on a 3-level MMU system is that you will
have to do four memory reads for one word of data.

So, as a quite general rule when doing computationally challenging 
algebraic stuff in a functional language: try hard to design your data 
representation in such a way that you minimize RAM access. If you can 
e.g. encode short lists of small integers into a fixnum-integer, then do 
so. A few shift and masking operations do not matter much for many 
pipelined processors, provided the code can be held in the cache. Memory 
access does. One can overdo it, though: if you need ten times more code to 
get rid of a simple memory access, you're on the wrong track. Code also 
has to be transported to the CPU core.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] how to "disable" GC?

[Eijiro Sumii]

From: "Thomas Fischbacher" <Thomas.Fischbacher@Physik.Uni-Muenchen.DE>
> > 2. Some programs get much slower for larger heaps, even though they
> >    don't seem to trigger any GC.  An example is such programs is given
> >    below.  Why is this?  (There also exist programs that are not
> >    affected at all, so this is not because of the initialization
> >    overhead of the runtime system.)
> 
> Quite in general, Cache hierarchy may be an issue here.

This is right, but let me clarify my question: Why is _anything_
heap-allocated, for example in the program below (given in my previous
message)?  According to the assembly and intermediate code in
ocamlopt, there is indeed something heap-allocated in the else-clause
of tak, but I don't know what this is for...  Are floting-point
numbers heap-allocated in ocamlopt on sparc??

| (**********************************************************************)
| let rec tak x y z =
|   if y >= x then z else
|   tak (tak (x -. 1.0) y z) (tak (y -. 1.0) z x) (tak (z -. 1.0) x y) in
| let n = 10.0 in
| print_int (int_of_float (1000000.0 *. tak (n *. 3.0) (n *. 2.0) (n *. 1.0)));
| print_newline ()
| (**********************************************************************)

> setenv OCAMLRUNPARAM 's=1000'
> time ./tak.ocamlopt
11000000
3.54u 0.01s 0:03.56 99.7%
> setenv OCAMLRUNPARAM 's=1000000000'
> time ./tak.ocamlopt
11000000
6.83u 1.50s 0:08.80 94.6%

Re: [Caml-list] how to "disable" GC?

[Kurt Welgehausen]

> Are floting-point numbers heap-allocated in ocamlopt on sparc?

Yes, I believe FP values are boxed on all platforms. You could
try keeping your values in an array, and see if that makes any
difference.

Also, see <http://caml.inria.fr/archives/200501/msg00125.html>
and related messages.

Regards

Re: [Caml-list] how to "disable" GC?

[Eijiro Sumii]

From: "Kurt Welgehausen" <kwel@kwel.net>
> > Are floting-point numbers heap-allocated in ocamlopt on sparc?
> 
> Yes, I believe FP values are boxed on all platforms. You could
> try keeping your values in an array, and see if that makes any
> difference.
> 
> Also, see <http://caml.inria.fr/archives/200501/msg00125.html>
> and related messages.

I see - so it seems to me that FP numbers are heap-allocated at least
when they are passed or returned as function arguments or results (to
support polymorphism, I suppose).  This explains well the behaviors of
ocamlopt (and its GC) that I've been experiencing.  Thanks for the
information!

	Eijiro

Re: [Caml-list] how to "disable" GC?

[Damien Doligez]

On Mar 13, 2005, at 04:57, Eijiro Sumii wrote:

>   setenv OCAMLRUNPARAM 's=1000000000,v=0x1ff'
>
> and its variants, but none of them seem to stop GC from happening -
> and once it happens, it's MUCH slower of course!  By the way, the
> machine has 8GB main memory.
>
> So, my questions are:
>
> 1. How does the GC happen at all when the minor heap is so huge?  The
>    programs don't seem to use so much memory anyway...

Look for "caml_check_urgent_gc" in the runtime sources and you'll see
that minor collections can be triggered even if the minor heap is not
full if needed, in order to do a slice of major GC.

So if you allocate some things that go directly into the major heap
(for example reasonably large arrays or strings) you need a big major
heap as well as a big minor heap:

   setenv OCAMLRUNPARAM 's=500M,h=500M,v=0x1ff'

-- Damien

Re: [Caml-list] how to "disable" GC?

[Ken Rose]

Damien Doligez wrote:

> So if you allocate some things that go directly into the major heap
> (for example reasonably large arrays or strings) you need a big major
> heap as well as a big minor heap:
> 
>   setenv OCAMLRUNPARAM 's=500M,h=500M,v=0x1ff'

Is there some way to do this from inside the OCaml program?  I don't see 
anything in a quick look at the documents for GC.

Thanks

  - ken

Re: [Caml-list] how to "disable" GC?

[Damien Doligez]

On Mar 14, 2005, at 16:17, Ken Rose wrote:

>> So if you allocate some things that go directly into the major heap
>> (for example reasonably large arrays or strings) you need a big major
>> heap as well as a big minor heap:
>>   setenv OCAMLRUNPARAM 's=500M,h=500M,v=0x1ff'
>
> Is there some way to do this from inside the OCaml program?  I don't 
> see anything in a quick look at the documents for GC.

Look for "minor_heap_size" and "verbose" in the "control" record type.
As for the initial heap size, of course it cannot be set from inside
the program, but "major_heap_increment" will do in this case.

Reference: < http://caml.inria.fr/pub/docs/manual-ocaml/libref/Gc.html >

-- Damien