From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 0133E7FA56 for ; Thu, 24 Jul 2014 17:36:04 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of fabrissimo@gmail.com) identity=pra; client-ip=209.85.216.47; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="fabrissimo@gmail.com"; x-sender="fabrissimo@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of fabrissimo@gmail.com designates 209.85.216.47 as permitted sender) identity=mailfrom; client-ip=209.85.216.47; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="fabrissimo@gmail.com"; x-sender="fabrissimo@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-qa0-f47.google.com) identity=helo; client-ip=209.85.216.47; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="fabrissimo@gmail.com"; x-sender="postmaster@mail-qa0-f47.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcCAAUn0VPRVdgvm2dsb2JhbABYg2BXBIJ0r0aVGIFhh0WBBggWEAEBAQEBBgsLCRQphAQBAQMBEhEdAS0LAQMBCwEFBQQHGh0CAiISAQUBChIGEwgKEIgMAwkIDZxYaosphQKKfycDCocuEQEFDo85gwOBTgWEcQWWPYFSkH8YKYFqgxA7Lw X-IPAS-Result: AkcCAAUn0VPRVdgvm2dsb2JhbABYg2BXBIJ0r0aVGIFhh0WBBggWEAEBAQEBBgsLCRQphAQBAQMBEhEdAS0LAQMBCwEFBQQHGh0CAiISAQUBChIGEwgKEIgMAwkIDZxYaosphQKKfycDCocuEQEFDo85gwOBTgWEcQWWPYFSkH8YKYFqgxA7Lw X-IronPort-AV: E=Sophos;i="5.01,724,1400018400"; d="scan'208";a="72701107" Received: from mail-qa0-f47.google.com ([209.85.216.47]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 24 Jul 2014 17:36:03 +0200 Received: by mail-qa0-f47.google.com with SMTP id i13so3134730qae.34 for ; Thu, 24 Jul 2014 08:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HU3Y0k4XWWkldUdCNYWy/RrAxRC9d+QB+4bfsu+e1t4=; b=AWp4eeAsHAeKPpxn+FPrVGLABxxxuKe6lvct2Bu2KRcrKkI1gQsEGTtVYo7Ex8VwuU yHv5kMrcbplCxvOiqE+7dg9MzuLvLYUCxCTVikSDFxgvBliGwauZAwQI0ZQdj7AJG0Kv t0V1GaIaZNkZzBbAyKqCbUgbo05R4YLuz4aD09X3a5zQEqAz7FPwC5pwPg7wvbMBo8UE vF/JXJE1LDL4Y6ALpr5gkz1JRveoDSPGnRgl19UoIKCeVD4KxdpqeKNwMRaYp/9tMdkK lHunNox1mfEsHAxo90bL/6GsCTFEK+9rWeBk5YL45ugwdV3Nmip3KQCHMxz458yrX0+F 9fjg== MIME-Version: 1.0 X-Received: by 10.140.102.117 with SMTP id v108mr15259354qge.93.1406216162678; Thu, 24 Jul 2014 08:36:02 -0700 (PDT) Sender: fabrissimo@gmail.com Received: by 10.96.115.104 with HTTP; Thu, 24 Jul 2014 08:36:02 -0700 (PDT) In-Reply-To: References: <21456.19915.45180.915211@gargle.gargle.HOWL> Date: Thu, 24 Jul 2014 17:36:02 +0200 X-Google-Sender-Auth: xs7vpJc_mf-zE5pKRwDw0JYZG5E Message-ID: From: Fabrice Le Fessant To: Nicolas Boulay Cc: Raoul Duke , OCaml Content-Type: multipart/alternative; boundary=001a11c16ec4dab82704fef236eb Subject: Re: [Caml-list] concurrent gc? --001a11c16ec4dab82704fef236eb Content-Type: text/plain; charset=UTF-8 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 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 : > > >> 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 --001a11c16ec4dab82704fef236eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Note that the cost of the GC does not automatically depend= s on the size of RAM. In many networking servers, memory is filled with str= ings, caching files on disk or content to be sent on the network. Such case= s make OCaml GC happy, since it does not have to manipulate many objects, a= nd 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 repre= sentation to decrease the number of blocks in the heap, I used to do it a l= ot 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 G= C could reduce latency a lot ?


201= 4-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.

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

--
Caml-list mailing list. =C2=A0Subscription management and archives:
ht= tps://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 F= ESSANT
Chercheur en Informatique
INRIA Paris Rocquencourt -- OCamlPro=
Programming Languages and Distributed Systems --001a11c16ec4dab82704fef236eb--