From: Nicolas Boulay <nicolas@boulay.name>
To: Fabrice Le Fessant <Fabrice.Le_fessant@inria.fr>
Cc: OCaml <caml-list@inria.fr>
Subject: Re: [Caml-list] concurrent gc?
Date: Fri, 25 Jul 2014 09:18:34 +0200 [thread overview]
Message-ID: <CAH+PdrCUJgTbU4LWC6D865Ag3i1HWcX7qPB2nNsRXcBzynFnjQ@mail.gmail.com> (raw)
In-Reply-To: <CAHvkLrMPXQU-vC3b7xTpNcHd0OHZJB=c4xGFqNCHsGfe8QkOjw@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2014-07-25 7:18 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-23 23:34 Raoul Duke
2014-07-24 0:05 ` John F. Carr
2014-07-24 0:08 ` Raoul Duke
2014-07-24 0:44 ` John F. Carr
2014-07-24 0:45 ` Raoul Duke
2014-07-24 15:24 ` Shayne Fletcher
2014-07-24 3:45 ` Malcolm Matalka
2014-07-24 5:58 ` Anthony Tavener
2014-07-28 11:20 ` Goswin von Brederlow
2014-07-24 6:58 ` Nicolas Boulay
2014-07-24 7:38 ` Malcolm Matalka
2014-07-24 15:36 ` Fabrice Le Fessant
2014-07-24 15:39 ` Malcolm Matalka
2014-07-24 16:44 ` Fabrice Le Fessant
2014-07-25 7:18 ` Nicolas Boulay [this message]
2014-07-28 11:26 ` Goswin von Brederlow
2014-07-28 11:24 ` Goswin von Brederlow
2014-07-28 17:34 ` Raoul Duke
2014-07-29 4:25 ` Gabriel Scherer
2014-07-29 4:49 ` ygrek
2014-07-29 10:01 ` Goswin von Brederlow
2014-07-29 10:29 ` ygrek
2014-07-31 11:10 ` Goswin von Brederlow
2014-07-29 17:23 ` Raoul Duke
2014-12-19 0:58 ` Jon Harrop
2014-07-31 14:26 ` Richard W.M. Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAH+PdrCUJgTbU4LWC6D865Ag3i1HWcX7qPB2nNsRXcBzynFnjQ@mail.gmail.com \
--to=nicolas@boulay.name \
--cc=Fabrice.Le_fessant@inria.fr \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox