Re: [Caml-list] Is OCaml fast?

["Török Edwin" <edwintorok@gmail.com>]

On Mon, 22 Nov 2010 17:46:49 +0100
Fabrice Le Fessant <fabrice@lefessant.net> wrote:

> 2010/11/22 Török Edwin <edwintorok@gmail.com>:
> > Isn't it possible for the GC to realise its doing too many
> > collections and increase the minor heap size on its own?
> 
> Indeed, it could notice that a lot of data is being moved to the major
> heap, and double its size in consequence, until a maximum limit is
> reached.

I did some benchmarks on 2 CPUs, and here are the wall clock times
for GC minor heap size:

"minorheap","      phenomII",,,"               core2",,,"cycle diff %"
,"              time",,"      cycles","time",,"      cycles",
32,"           17.76","17.74",56.8," 48.60","48.86",58.48,2.96
64,"           16.81","16.80",53.78,"44.79","44.79",53.75,-0.06
128,"          15.41","15.38",49.26,"41.38","40.76",49.28,0.04
256,"          14.39","14.35",45.98,"39.75","38.98",47.24,2.74
512,"          12.97","13.15",41.79,"35.75","35.59",42.8,2.42
1024,"         12.89","12.94",41.33,"33.57","33.13",40.02,-3.17
2048,"         11.05","11.09",35.42,"29.26","29.12",35.03,-1.1
4096,"         9.79"," 9.81",31.36,"26.21","25.96",31.3,-0.19
8192,"         8.71"," 8.85",28.1," 23.36","23.34",28.02,-0.28
16384,"        7.89"," 7.86",25.2," 21.41","21.54",25.77,2.26
32768,"        7.55"," 7.55",24.16,"20.74","20.88",24.97,3.35

(minorheap is in KWords, time is in seconds, cycles is divided by 10^9)

Increasing minor heap beyond that yielded no improvement (number of
minor heap collections stayed the same).

phenomII has 64 Kb L1 data cache, 512Kb L2 cache, 6144Kb L3 cache
(shared), runs at 3.2Ghz. That would be 516k words if only 1 core used.

core2  has 32 Kb L1 data cache, 4MB L2 cache, runs at 1.2Ghz.
That would be 840k words if only 1 core used.

Both used exact same binaries on 64-bit Linux, ocaml 3.11.2.

Despite the difference in CPUs and heap sizes the number of CPU cycles
spent for a given size of the minor heap is about the same (within 3%
difference).

Not sure what the max should be for the minor heap increase, but based
on this benchmark increasing size of minor heap never slows down the
program. Even when size of minor heap exceeds what fits in the cache.
I guess there is another microbenchmark that can show the opposite
though.

Is there some real world benchmark for OCaml's GC that can be used
to get some better values for minor heap size based on CPU's L2/L3 size
(as suggested in the 'Optimizing garbage collection' thread)?


> 
>  The problem is that it is the kind of things that are application
> dependent,

Yes, maybe optimal size of minor heap doesn't depend on CPU's cache
size but on the application, in which case a heuristic for
increasing/decreasing the heap size may be better?

> and should be put in the program itself (the program would
> have a trigger on each minor heap collection, and, depending on the
> moved bytes, would increase the size of the minor heap). The problem
> is that the Shootout does not allow that, so the winner is the
> language whose runtime allocates the most memory at the beginnning...

If tuning minor heap can double performance of the program, then the GC
should have some heuristics to tune it automatically. Sure applications
which are not happy with that tuning should tune it themselves.

Best regards,
--Edwin