[Caml-list] concurrent gc?

[Caml-list] concurrent gc?

[Raoul Duke]

extremely clueless question warning, both generally technically but
also vis-a-vie ocaml specifically:

so even if ocaml can't so easily be made to support multiple threads
of ocaml code, could the gc be moved off to another thread? so that it
could run on another core. would that be of any benefit?

Re: [Caml-list] concurrent gc?

[John F. Carr]

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%.

For technical reasons, offloading major collections in OCaml is easier
than offloading minor collections, so the potential benefit is less.

 > extremely clueless question warning, both generally technically but
 > also vis-a-vie ocaml specifically:
 > 
 > so even if ocaml can't so easily be made to support multiple threads
 > of ocaml code, could the gc be moved off to another thread? so that it
 > could run on another core. would that be of any benefit?

Re: [Caml-list] concurrent gc?

[Raoul Duke]

> 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.

Re: [Caml-list] concurrent gc?

[John F. Carr]

 > 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? :)

OCaml's runtime is designed around the assumption that access to the
minor heap is fast and the minor heap is only emptied when the program
is stopped.  More generally, no object moves except when the program
is stopped.  Every minor collection moves objects, while most major
collections do not.  The runtime can even be told not to move objects
during a major collection.

So minor collections have to happen while the main program is stopped,
or you have a large rather than a small change to the compiler-runtime
interface.

Full major collections are infrequent.  The runtime is designed to do
some amount of major collection work after each minor GC.  For
example, it might mark 10000 objects before restarting the program,
even though there are a million objects in the heap.  It is this
"slice" of work that could be overlapped with execution of the main
program.

Before writing a concurrent garbage collector, try

1. Turn down the amount of work done at each major collection slice.

2. Reduce the size of the minor heap.

See the Gc module and OCAMLRUNPARAM environment variable.

Re: [Caml-list] concurrent gc?

[Raoul Duke]

> See the Gc module and OCAMLRUNPARAM environment variable.

ok! many thanks!

Re: [Caml-list] concurrent gc?

[Malcolm Matalka]

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

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: 1934 bytes --]

Re: [Caml-list] concurrent gc?

[Anthony Tavener]

[-- 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 --]

Re: [Caml-list] concurrent gc?

[Nicolas Boulay]

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

What about server that use ~60GB of RAM ? Todays server are sold with 32 to
256 GB of RAM and lot of cpu core.
Maybe in such extreme cases, offloading the major collection of the GC
could reduce latency a lot ?


2014-07-24 2:05 GMT+02:00 John F. Carr <jfc@mit.edu>:

>
> 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%.
>
> For technical reasons, offloading major collections in OCaml is easier
> than offloading minor collections, so the potential benefit is less.
>
>  > extremely clueless question warning, both generally technically but
>  > also vis-a-vie ocaml specifically:
>  >
>  > so even if ocaml can't so easily be made to support multiple threads
>  > of ocaml code, could the gc be moved off to another thread? so that it
>  > could run on another core. would that be of any benefit?
>
> --
> 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: 1874 bytes --]

Re: [Caml-list] concurrent gc?

[Malcolm Matalka]

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

It's highly dependent on the situation but in my experience the goal is
almost always to avoid doing a collection over all 60 gb.  It's expensive
no matter how you do it.  Solutions include spreading the data over
multiple processes and/or moving the data outside the managed heap.
Ocaml-ancient is worth looking at as well.
Den 24 jul 2014 09:01 skrev "Nicolas Boulay" <nicolas@boulay.name>:

> What about server that use ~60GB of RAM ? Todays server are sold with 32
> to 256 GB of RAM and lot of cpu core.
> Maybe in such extreme cases, offloading the major collection of the GC
> could reduce latency a lot ?
>
>
> 2014-07-24 2:05 GMT+02:00 John F. Carr <jfc@mit.edu>:
>
>>
>> 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%.
>>
>> For technical reasons, offloading major collections in OCaml is easier
>> than offloading minor collections, so the potential benefit is less.
>>
>>  > extremely clueless question warning, both generally technically but
>>  > also vis-a-vie ocaml specifically:
>>  >
>>  > so even if ocaml can't so easily be made to support multiple threads
>>  > of ocaml code, could the gc be moved off to another thread? so that it
>>  > could run on another core. would that be of any benefit?
>>
>> --
>> 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: 2506 bytes --]

Re: [Caml-list] concurrent gc?

[Shayne Fletcher]

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

On Wed, Jul 23, 2014 at 8:45 PM, Raoul Duke <raould@gmail.com> wrote:

> > See the Gc module and OCAMLRUNPARAM environment variable.
>
> ok! many thanks!


​Fascinating thread Raoul. Nice question!

-- 
Shayne Fletcher

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

Re: [Caml-list] concurrent gc?

[Fabrice Le Fessant]

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

Note that the cost of the GC does not automatically depends on the size of
RAM. In many networking servers, memory is filled with strings, caching
files on disk or content to be sent on the network. Such cases make OCaml
GC happy, since it does not have to manipulate many objects, and it won't
scan strings for pointers within them. There are also other tricks to
improve the GC behavior: you might want to change the data representation
to decrease the number of blocks in the heap, I used to do it a lot when
doing computations on millions of entries that would not otherwise stay in
memory.

--Fabrice


On Thu, Jul 24, 2014 at 8:58 AM, Nicolas Boulay <nicolas@boulay.name> wrote:

> What about server that use ~60GB of RAM ? Todays server are sold with 32
> to 256 GB of RAM and lot of cpu core.
> Maybe in such extreme cases, offloading the major collection of the GC
> could reduce latency a lot ?
>
>
> 2014-07-24 2:05 GMT+02:00 John F. Carr <jfc@mit.edu>:
>
>
>> 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%.
>>
>> For technical reasons, offloading major collections in OCaml is easier
>> than offloading minor collections, so the potential benefit is less.
>>
>>  > extremely clueless question warning, both generally technically but
>>  > also vis-a-vie ocaml specifically:
>>  >
>>  > so even if ocaml can't so easily be made to support multiple threads
>>  > of ocaml code, could the gc be moved off to another thread? so that it
>>  > could run on another core. would that be of any benefit?
>>
>> --
>> 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
>>
>
>


-- 
Fabrice LE FESSANT
Chercheur en Informatique
INRIA Paris Rocquencourt -- OCamlPro
Programming Languages and Distributed Systems

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

Re: [Caml-list] concurrent gc?

[Malcolm Matalka]

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

Cool, what sort of tricks can you do to reduce the number of blocks?
Den 24 jul 2014 17:36 skrev "Fabrice Le Fessant" <
Fabrice.Le_fessant@inria.fr>:

> Note that the cost of the GC does not automatically depends on the size of
> RAM. In many networking servers, memory is filled with strings, caching
> files on disk or content to be sent on the network. Such cases make OCaml
> GC happy, since it does not have to manipulate many objects, and it won't
> scan strings for pointers within them. There are also other tricks to
> improve the GC behavior: you might want to change the data representation
> to decrease the number of blocks in the heap, I used to do it a lot when
> doing computations on millions of entries that would not otherwise stay in
> memory.
>
> --Fabrice
>
>
> On Thu, Jul 24, 2014 at 8:58 AM, Nicolas Boulay <nicolas@boulay.name>
> wrote:
>
>> What about server that use ~60GB of RAM ? Todays server are sold with 32
>> to 256 GB of RAM and lot of cpu core.
>> Maybe in such extreme cases, offloading the major collection of the GC
>> could reduce latency a lot ?
>>
>>
>> 2014-07-24 2:05 GMT+02:00 John F. Carr <jfc@mit.edu>:
>>
>>
>>> 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%.
>>>
>>> For technical reasons, offloading major collections in OCaml is easier
>>> than offloading minor collections, so the potential benefit is less.
>>>
>>>  > extremely clueless question warning, both generally technically but
>>>  > also vis-a-vie ocaml specifically:
>>>  >
>>>  > so even if ocaml can't so easily be made to support multiple threads
>>>  > of ocaml code, could the gc be moved off to another thread? so that it
>>>  > could run on another core. would that be of any benefit?
>>>
>>> --
>>> 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
>>>
>>
>>
>
>
> --
> Fabrice LE FESSANT
> Chercheur en Informatique
> INRIA Paris Rocquencourt -- OCamlPro
> Programming Languages and Distributed Systems
>

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

Re: [Caml-list] concurrent gc?

[Fabrice Le Fessant]

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

Well, it is hard to enumerate. The basic idea is to find, for each data
structure, the best trade-off between efficient operations and space
occupation. The simplest example is to decide between using lists or
arrays. Arrays use less space (unless you use hash-consing or you share the
end of the lists), but if you don't know the final size you need, you will
finish either pre-allocating longer arrays than you need, or re-allocating
arrays too often, or switching between lists and arrays... In the end, it
really depends on what an application does.

There are also other tricks such as changing the tag of a block to avoid
scanning, but I wouldn't advise to use it unless you really know what you
are doing...

--Fabrice


On Thu, Jul 24, 2014 at 5:39 PM, Malcolm Matalka <mmatalka@gmail.com> wrote:

> Cool, what sort of tricks can you do to reduce the number of blocks?
> Den 24 jul 2014 17:36 skrev "Fabrice Le Fessant" <
> Fabrice.Le_fessant@inria.fr>:
>
> Note that the cost of the GC does not automatically depends on the size of
>> RAM. In many networking servers, memory is filled with strings, caching
>> files on disk or content to be sent on the network. Such cases make OCaml
>> GC happy, since it does not have to manipulate many objects, and it won't
>> scan strings for pointers within them. There are also other tricks to
>> improve the GC behavior: you might want to change the data representation
>> to decrease the number of blocks in the heap, I used to do it a lot when
>> doing computations on millions of entries that would not otherwise stay in
>> memory.
>>
>> --Fabrice
>>
>>
>> On Thu, Jul 24, 2014 at 8:58 AM, Nicolas Boulay <nicolas@boulay.name>
>> wrote:
>>
>>> What about server that use ~60GB of RAM ? Todays server are sold with 32
>>> to 256 GB of RAM and lot of cpu core.
>>> Maybe in such extreme cases, offloading the major collection of the GC
>>> could reduce latency a lot ?
>>>
>>>
>>> 2014-07-24 2:05 GMT+02:00 John F. Carr <jfc@mit.edu>:
>>>
>>>
>>>> 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%.
>>>>
>>>> For technical reasons, offloading major collections in OCaml is easier
>>>> than offloading minor collections, so the potential benefit is less.
>>>>
>>>>  > extremely clueless question warning, both generally technically but
>>>>  > also vis-a-vie ocaml specifically:
>>>>  >
>>>>  > so even if ocaml can't so easily be made to support multiple threads
>>>>  > of ocaml code, could the gc be moved off to another thread? so that
>>>> it
>>>>  > could run on another core. would that be of any benefit?
>>>>
>>>> --
>>>> 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
>>>>
>>>
>>>
>>
>>
>> --
>> Fabrice LE FESSANT
>> Chercheur en Informatique
>> INRIA Paris Rocquencourt -- OCamlPro
>> Programming Languages and Distributed Systems
>>
>


-- 
Fabrice LE FESSANT
Chercheur en Informatique
INRIA Paris Rocquencourt -- OCamlPro
Programming Languages and Distributed Systems

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

Re: [Caml-list] concurrent gc?

[Nicolas Boulay]

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

It's not possible to create a generic "list of array" that behave almost
like a list, with a chunk with a nice size (4KB ?)


2014-07-24 18:44 GMT+02:00 Fabrice Le Fessant <Fabrice.Le_fessant@inria.fr>:

> Well, it is hard to enumerate. The basic idea is to find, for each data
> structure, the best trade-off between efficient operations and space
> occupation. The simplest example is to decide between using lists or
> arrays. Arrays use less space (unless you use hash-consing or you share the
> end of the lists), but if you don't know the final size you need, you will
> finish either pre-allocating longer arrays than you need, or re-allocating
> arrays too often, or switching between lists and arrays... In the end, it
> really depends on what an application does.
>
> There are also other tricks such as changing the tag of a block to avoid
> scanning, but I wouldn't advise to use it unless you really know what you
> are doing...
>
> --Fabrice
>
>
> On Thu, Jul 24, 2014 at 5:39 PM, Malcolm Matalka <mmatalka@gmail.com>
> wrote:
>
>> Cool, what sort of tricks can you do to reduce the number of blocks?
>> Den 24 jul 2014 17:36 skrev "Fabrice Le Fessant" <
>> Fabrice.Le_fessant@inria.fr>:
>>
>>  Note that the cost of the GC does not automatically depends on the size
>>> of RAM. In many networking servers, memory is filled with strings, caching
>>> files on disk or content to be sent on the network. Such cases make OCaml
>>> GC happy, since it does not have to manipulate many objects, and it won't
>>> scan strings for pointers within them. There are also other tricks to
>>> improve the GC behavior: you might want to change the data representation
>>> to decrease the number of blocks in the heap, I used to do it a lot when
>>> doing computations on millions of entries that would not otherwise stay in
>>> memory.
>>>
>>> --Fabrice
>>>
>>>
>>> On Thu, Jul 24, 2014 at 8:58 AM, Nicolas Boulay <nicolas@boulay.name>
>>> wrote:
>>>
>>>> What about server that use ~60GB of RAM ? Todays server are sold with
>>>> 32 to 256 GB of RAM and lot of cpu core.
>>>> Maybe in such extreme cases, offloading the major collection of the GC
>>>> could reduce latency a lot ?
>>>>
>>>>
>>>> 2014-07-24 2:05 GMT+02:00 John F. Carr <jfc@mit.edu>:
>>>>
>>>>
>>>>> 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%.
>>>>>
>>>>> For technical reasons, offloading major collections in OCaml is easier
>>>>> than offloading minor collections, so the potential benefit is less.
>>>>>
>>>>>  > extremely clueless question warning, both generally technically but
>>>>>  > also vis-a-vie ocaml specifically:
>>>>>  >
>>>>>  > so even if ocaml can't so easily be made to support multiple threads
>>>>>  > of ocaml code, could the gc be moved off to another thread? so that
>>>>> it
>>>>>  > could run on another core. would that be of any benefit?
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Fabrice LE FESSANT
>>> Chercheur en Informatique
>>> INRIA Paris Rocquencourt -- OCamlPro
>>> Programming Languages and Distributed Systems
>>>
>>
>
>
> --
> Fabrice LE FESSANT
> Chercheur en Informatique
> INRIA Paris Rocquencourt -- OCamlPro
> Programming Languages and Distributed Systems
>

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

Re: [Caml-list] concurrent gc?

[Goswin von Brederlow]

On Wed, Jul 23, 2014 at 11:58:57PM -0600, Anthony Tavener wrote:
> 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

Actually what you need to do there is to trigger the GC explicitly
inbetween frames and fine tune the GC so it doesn't run mid-frame at
all (make the minor heap large enough).

That also tends to improve the GC efficiency since for a frame you
will have lots of temporary allocations that won't outlive the frame.
So at the end of each frame is the best time to clean up the minor
heap.

MfG
	Goswin

Re: [Caml-list] concurrent gc?

[Goswin von Brederlow]

On Thu, Jul 24, 2014 at 06:44:21PM +0200, Fabrice Le Fessant wrote:
> There are also other tricks such as changing the tag of a block to avoid
> scanning, but I wouldn't advise to use it unless you really know what you
> are doing...
> 
> --Fabrice

That is actualy something that should be fixed in the compiler. There
are some special cases that use special tags, e.g. a record only
containing floats will be tagges as float array. But any record that
contains no pointers should be tagged so it isn't needlessly scanned.
Afaik that doesn't happen yet.

MfG
	Goswin

Re: [Caml-list] concurrent gc?

[Goswin von Brederlow]

On Fri, Jul 25, 2014 at 09:18:34AM +0200, Nicolas Boulay wrote:
> It's not possible to create a generic "list of array" that behave almost
> like a list, with a chunk with a nice size (4KB ?)

Easy enough to implement. You just have to rewrite your code you use
it.

MfG
	Goswin

Re: [Caml-list] concurrent gc?

[Raoul Duke]

>> There are also other tricks such as changing the tag of a block to avoid
>> scanning, but I wouldn't advise to use it unless you really know what you
>> are doing...
> That is actualy something that should be fixed in the compiler. There
> are some special cases that use special tags, e.g. a record only
> containing floats will be tagges as float array. But any record that
> contains no pointers should be tagged so it isn't needlessly scanned.
> Afaik that doesn't happen yet.

anybody who understands those words willing to open a bug report on it? ;-)

Re: [Caml-list] concurrent gc?

[Gabriel Scherer]

This is not a bug, at best a feature request (of the kind "we've
already talked about plenty of times and nobody stepped forward to do
actual work to demonstrate usefulness"). You can optimize your data
representation this or that way, and they will work better or this or
that workflow.

Do you have practical experience with OCaml programs with unacceptable
pauses, or is this discussion just premature GC optimization? Having a
concrete example to work with could be interesting.

On Mon, Jul 28, 2014 at 7:34 PM, Raoul Duke <raould@gmail.com> wrote:
>>> There are also other tricks such as changing the tag of a block to avoid
>>> scanning, but I wouldn't advise to use it unless you really know what you
>>> are doing...
>> That is actualy something that should be fixed in the compiler. There
>> are some special cases that use special tags, e.g. a record only
>> containing floats will be tagges as float array. But any record that
>> contains no pointers should be tagged so it isn't needlessly scanned.
>> Afaik that doesn't happen yet.
>
> anybody who understands those words willing to open a bug report on it? ;-)
>
> --
> 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

Re: [Caml-list] concurrent gc?

[ygrek]

Hello,

 See also the pros and cons in http://caml.inria.fr/mantis/view.php?id=5010

-- 

Re: [Caml-list] concurrent gc?

[Goswin von Brederlow]

On Tue, Jul 29, 2014 at 12:49:19PM +0800, ygrek wrote:
> Hello,
> 
>  See also the pros and cons in http://caml.inria.fr/mantis/view.php?id=5010

"pros and cons"?

The issue talks about arrays and xleroy mentioned that the magic that
is used to tag float arrays as such does not extend to e.g int arrays
and therefore, since it needs to be a runtime thing, special tagging
won't work there. Seems ther is only one big con.


But that doesn't hold for records. The type of a record is known at
compile time and the compiler knows it if can contain any pointer or
not. This gets a bit tricky with polymorphic records, e.g.:

type 'a t = { x : 'a }

Then "int t" has no pointers but "int list t" does. Since 'a t records
can be created in polymorphic functions that means even "int t" can
not be tagged no-scan or you would end up with different tags
depending on who created the record.

Tagging records without pointer would only be for records without
polymorphic members (more specific for !E 'a . 'a t contains pointer),
e.g.

type 'a x = int
type 'a t = { x: 'a x; y: int; }

That somewhat limits the use case but avoids the problem of runtime
detection of the type.

MfG
	Goswin

Re: [Caml-list] concurrent gc?

[ygrek]

On Tue, 29 Jul 2014 12:01:22 +0200
Goswin von Brederlow <goswin-v-b@web.de> wrote:

> The issue talks about arrays and xleroy mentioned that the magic that
> is used to tag float arrays as such does not extend to e.g int arrays
> and therefore, since it needs to be a runtime thing, special tagging
> won't work there. Seems ther is only one big con.

The "pro" is the noticeable speedup, see the link in the issue.

I wonder whether modifying caml_compare to not distinguish 0 and "noscan" tag would be worthwhile..

Re: [Caml-list] concurrent gc?

[Raoul Duke]

> Do you have practical experience with OCaml programs with unacceptable
> pauses, or is this discussion just premature GC optimization? Having a
> concrete example to work with could be interesting.

this is premature gc optimization.

there was a time when i would have had real data, but there were FFI
bugs (as far as i could tell) with ocaml and one of the labltk or
whatever opengl libraries and it wasn't ever something resolved so i
gave up and moved on to other ecosystems.

so were i to get back into ocaml it would be with some trepidation
since i've been fairly burned a bit before with it. of course, mostly
all systems will burn me one way or another. with haxe + hxcpp on
android, the gc seems to be what is killing me, at least on the
low-end devices which i assume have smaller cpu caches. something.

so i've been looking at other things again. ocaml has a lot going for
it on paper, i've always been a fan of it, i try to attend local ocaml
meetups, etc. so i'm not a complete hater. but i really do not want
there to be any gc pauses or as few as possible so it is fun to learn
if i have any way to influence that, and how hard that can be to
achieve. e.g. with haxe+hxpp on android i think i'd have to really
dive into the sources and get the android nkd profiling working etc.
etc. etc. which feels like way too much work.

:-)

Re: [Caml-list] concurrent gc?

[Goswin von Brederlow]

On Tue, Jul 29, 2014 at 06:29:01PM +0800, ygrek wrote:
> On Tue, 29 Jul 2014 12:01:22 +0200
> Goswin von Brederlow <goswin-v-b@web.de> wrote:
> 
> > The issue talks about arrays and xleroy mentioned that the magic that
> > is used to tag float arrays as such does not extend to e.g int arrays
> > and therefore, since it needs to be a runtime thing, special tagging
> > won't work there. Seems ther is only one big con.
> 
> The "pro" is the noticeable speedup, see the link in the issue.
> 
> I wonder whether modifying caml_compare to not distinguish 0 and "noscan" tag would be worthwhile..

If that is the only thing holding this back then please do.

What about marshaling? Or code that depends on Obj and looks at the
tag of things (which deserves to break :)?

MfG
	Goswin

Re: [Caml-list] concurrent gc?

[Richard W.M. Jones]

One thing that doesn't seem to have been mentioned:

Avoid going into swap.  If your GC is trying to collect objects which
have been swapped out, everything will grind to a halt very quickly.

Rich.

-- 
Richard Jones
Red Hat

RE: [Caml-list] concurrent gc?

[Jon Harrop]

Raoul Duke wrote:
> the gc seems to be what is killing me, at least on the low-end devices which i assume have smaller cpu caches

Make sure the minor GC size fits into the L1 cache.

Cheers,
Jon.