Re: [Caml-list] concurrent gc?

[Nicolas Boulay <nicolas@boulay.name>]

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