Re: AW: [Caml-list] What is triggering a lot of GC work?

[Gabriel Scherer <gabriel.scherer@gmail.com>]

Thanks for the friendly poking. I did get some code (I've actually
been surprised by how dedicated some submitters one, eg. Edwin Török),
but my plate has been full non-stop since and I haven't yet taken the
time to put this into shape. It's on my TODO list and I hope to share
some results in the coming weeks.

Regarding the interesting battle story from Gerd, my own idea was to
"oldify" the values before inserting them in the array, in order not
to fire the write barrier. Oldifying values is costly as well, so I'm
not sure if that's interesting if the array is long-lived but the
elements short-lived. And more importantly, the oldifying interface
is, to my knowledge, not exposed to end-users (while it's possible
through the C interface to allocate directly in the old region), so
this cannot be written and tested without ugly hacks right now. I'd
still be curious to know how this solution would compare to the
others.

On Mon, Feb 25, 2013 at 4:45 PM, Alain Frisch <alain.frisch@lexifi.com> wrote:
> On 02/25/2013 02:31 PM, Gerd Stolpmann wrote:
>>
>> This can have counter-intuitive consequences. Yesterday I sped an
>> imperative program up by adding allocations!
>
>
> This is really an interesting scenario, thanks for sharing!
>
> Two other approaches to addressing the same performance issue could have
> been:
>
>  1. increase the size of the minor heap so that your array stays in it long
> enough;
>
>  2. try to reduce the number of other allocations.
>
> Did you try one of these approaches as well?  (1 in particular is
> particularly easy to test.)
>
>
>
> Gabriel Scherer recently called the community to share representative
> "benchmarks", in order to help core developers target optimization efforts
> to where they are useful:
>
> http://gallium.inria.fr/~scherer/gagallium/we-need-a-representative-benchmark-suite/
>
> Gabriel: except from LexiFi's contribution, did you get any code?  Gerd: it
> would be great if you could share the code you mention above; is it an
> option?  There are a number of optimizations which have been proposed
> (related to boxing of floats, compilation strategy for let-binding on
> tuples, etc), which could reduce significantly the allocation rate of some
> programs.  In my experience, this reduction can be observed on real-sized
> programs, but it does not translate to noticeable speedups. It might be the
> case that your program would benefit from such optimizations.  Having access
> to the code would be very useful!
>
>
> Alain
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs