Török Edwin <edwintorok@gmail.com> writes:

> On Mon, 22 Nov 2010 15:36:30 +0100
> bluestorm <bluestorm.dylc@gmail.com> wrote:
>
>> On Mon, Nov 22, 2010 at 3:04 PM, Gerd Stolpmann
>> <info@gerd-stolpmann.de>wrote:
>> 
>> > I think the shootout is not a good data source. There are definitely
>> > some very poor Ocaml results there, so I'd guess the shootout got
>> > recently more attention by enthusiasts of other languages, and the
>> > current Ocaml programs there are not very good. (I remember Ocaml
>> > was #1 at the shootout a few years ago, faster than C.) So maybe a
>> > good opportunity to post better Ocaml solutions there?
>> >
>> 
>> As Sylvain noticed, some (in not most) of the OCaml poor performances
>> in the shootout are actually not due to bad OCaml programs, but to
>> arbitrary restrictions in the shootout rules. For example, one of the
>> bad-performing benchmark for OCaml is the binary-tree benchmark,
>> where it is nearly four times slower than C, but on closer inspection
>> you discover that this is due to the arbitrary choice to forbid any
>> change of the GC parameters. With appropriate GC parameters, the very
>> same OCaml program is exactly as fast as C.
>> 
>> http://shootout.alioth.debian.org/u32/performance.php?test=binarytrees
>> 
>> « Note: these programs are being measured with *the default initial
>> heap size* - the measurements may be very different with a larger
>> initial heap size or GC tuning. »
>> C version : 12.11 secs
>> OCaml version : 47.22 secs
>> OCaml version with GC parameters tuned ("interesting alternative"
>> section) : 12.67 secs
>> 
>> 
>> Therefore, there is nothing that can be changed to the OCaml
>> submission for this benchmark to improve performances, except
>> changing the default GC parameters; while this might be a good idea
>> in general, changing it only for the sake of shootout-obsessed people
>> is ridiculous.
>
> Isn't it possible for the GC to realise its doing too many collections
> and increase the minor heap size on its own?

Maybe. The GC would have to see that with a larger minor heap it has
sufficient space so that most values die before the collection. It could
see that most values die after 1 major sweep and increasing the minor
heap would likely keep them out of the major heap alltogether.

> Or isn't it possible to determine at compile time an approximation for
> a good heap size, and use that?

Usualy that is dependent on the input.

MfG
        Goswin