caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Malcolm Matalka <mmatalka@gmail.com>
To: Fabrice Le Fessant <Fabrice.Le_fessant@inria.fr>
Cc: Raoul Duke <raould@gmail.com>, OCaml <caml-list@inria.fr>,
	 Nicolas Boulay <nicolas@boulay.name>
Subject: Re: [Caml-list] concurrent gc?
Date: Thu, 24 Jul 2014 17:39:23 +0200	[thread overview]
Message-ID: <CAKziXDWdKWyR5LigJXVk=ahp9SO+JOrH0CdqR6_ndiKh9yuqXA@mail.gmail.com> (raw)
In-Reply-To: <CAHvkLrP3jJ0dp+rb4aUAQ4T5qNKYAi0W0KeLe3JNjLHFimZYfg@mail.gmail.com>

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

  reply	other threads:[~2014-07-24 15:39 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 [this message]
2014-07-24 16:44         ` Fabrice Le Fessant
2014-07-25  7:18           ` Nicolas Boulay
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='CAKziXDWdKWyR5LigJXVk=ahp9SO+JOrH0CdqR6_ndiKh9yuqXA@mail.gmail.com' \
    --to=mmatalka@gmail.com \
    --cc=Fabrice.Le_fessant@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=nicolas@boulay.name \
    --cc=raould@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).