Re: [Caml-list] concurrent gc?

[Anthony Tavener <anthony.tavener@gmail.com>]

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

I agree with Malcolm's experience, and my situation might be similar to
yours: games -- a lot of allocations at high framerate. I'm guessing this
from how evil you consider pauses to be. ;) In some circumstances I *have*
experienced hitching, which did turn out to be due to GC -- but then I'd
find I was creating a pathological case. You can't expect to throw a
completely arbitrary workload at the GC and expect it to remain invisible.
Just as with allocations by hand in C, even with sophisticated custom
allocators -- you still need to use dynamic allocations wisely. Here, I
think the biggest problem is when you have a GC, you lose awareness of the
allocations you're triggering.

I doubt I'd use OCaml to write the bulk of a leading-edge (in graphics
fidelity, framerate, and scene size) FPS game engine, competing with Unreal
or Crytek... but it's suitable for less intensive requirements. Then again,
one might follow the approach of FFTW and use OCaml to write a generator
which outputs a C-based renderer. :D


On Wed, Jul 23, 2014 at 9:45 PM, Malcolm Matalka <mmatalka@gmail.com> wrote:

> While it may not help you, ocamls GC only kicks off during an allocation
> so you can at least construct an important section of code to not have a GC
> occur in it.  But I don't think that would help for your situation.
>
> Is your concern more general or do you have a specific situation?  Ime it
> takes quite a but of work to cause a noticeable GC pause in ocaml.
> Den 24 jul 2014 02:09 skrev "Raoul Duke" <raould@gmail.com>:
>
> > Most programs spend a minority of their time in garbage collection.
>> > Even if the new GC thread did not slow down the main program,
>> > possible speedup would be less than 2x, probably well under 50%.
>>
>> thanks! gotchya.
>>
>> I should have noted that my main concern is with pauses, not with
>> overall speedup. In other words: in interactive apps, pauses are
>> eeeeeevil.
>>
>> > For technical reasons, offloading major collections in OCaml is easier
>> > than offloading minor collections, so the potential benefit is less.
>>
>> I am guessing you mean that major collections just don't happen that
>> often, at least if people write their code in a non-pathalogical
>> fashion? :)
>>
>> sincerely.
>>
>> --
>> 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
>>
>

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