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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 370B97FA56 for ; Fri, 25 Jul 2014 09:18:37 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of nicolas.boulay@gmail.com) identity=pra; client-ip=209.85.213.182; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="nicolas.boulay@gmail.com"; x-sender="nicolas.boulay@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of nicolas.boulay@gmail.com designates 209.85.213.182 as permitted sender) identity=mailfrom; client-ip=209.85.213.182; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="nicolas.boulay@gmail.com"; x-sender="nicolas.boulay@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ig0-f182.google.com) identity=helo; client-ip=209.85.213.182; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="nicolas.boulay@gmail.com"; x-sender="postmaster@mail-ig0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYBAAIE0lPRVdW2m2dsb2JhbABZg2BXBIJ0r3qVGYFhh0WBCwgWEAEBAQEBBgsLCRQphAMBAQEDARIRHQEtCwEDAQsBBQULDQ0dAgIhARIBBQEKEgYTCAoQiAwDCQgNm31qiymFAopmJwMKhyARAQUOjRCCKYMDgU8FhHIFlEOCA4FSjFWELxgpgWuDEDsv X-IPAS-Result: ApYBAAIE0lPRVdW2m2dsb2JhbABZg2BXBIJ0r3qVGYFhh0WBCwgWEAEBAQEBBgsLCRQphAMBAQEDARIRHQEtCwEDAQsBBQULDQ0dAgIhARIBBQEKEgYTCAoQiAwDCQgNm31qiymFAopmJwMKhyARAQUOjRCCKYMDgU8FhHIFlEOCA4FSjFWELxgpgWuDEDsv X-IronPort-AV: E=Sophos;i="5.01,729,1400018400"; d="scan'208";a="86923872" Received: from mail-ig0-f182.google.com ([209.85.213.182]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 25 Jul 2014 09:18:36 +0200 Received: by mail-ig0-f182.google.com with SMTP id c1so414080igq.9 for ; Fri, 25 Jul 2014 00:18:35 -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=CMM3llQhEBLb2Dk1GwVRdK8Fe3ykEdobpVA+gHzLt/c=; b=Pna9qjnhywTOwA+06jQEYYGgAABEzNgEpPOeIJ5eco3SnW5S8tT5tKlxgbGkUGDFkn RC/iXd42SQBwty56WxDvsiIkcb/S4g65BskBlCZxXuEa5/F4FPBrHVio3qzRkBMDBbNy FrrWKdAUJbHxLzdXYIbgWqwvDSOZaUSq5ArPWeU8ovVez9hbBd9CWQWOMQRVHafiu9Wq KVIJjcZCC1CtWqQ7xHvuE15hW5PMOtmYOmK+lMKifudJ1HEu1zmB/JKeNjwOqEjQJGSa uZQYWuCVVYCA6zpeW+OVPi80Z+m1eq/lhnJ7W9NlgmxV9S0QJGlcTw4btv52bX4fN1fF ZV3g== MIME-Version: 1.0 X-Received: by 10.42.107.145 with SMTP id d17mr17715998icp.61.1406272714928; Fri, 25 Jul 2014 00:18:34 -0700 (PDT) Sender: nicolas.boulay@gmail.com Received: by 10.50.73.131 with HTTP; Fri, 25 Jul 2014 00:18:34 -0700 (PDT) In-Reply-To: References: <21456.19915.45180.915211@gargle.gargle.HOWL> Date: Fri, 25 Jul 2014 09:18:34 +0200 X-Google-Sender-Auth: wrFW1lMw39ZgClp0XmOiXwlPbYM Message-ID: From: Nicolas Boulay To: Fabrice Le Fessant Cc: OCaml Content-Type: multipart/alternative; boundary=20cf301fb60da176e504feff6132 X-Validation-by: nicolas@boulay.name Subject: Re: [Caml-list] concurrent gc? --20cf301fb60da176e504feff6132 Content-Type: text/plain; charset=UTF-8 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 : > 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 > 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 >>> 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 >>> >> > > > -- > Fabrice LE FESSANT > Chercheur en Informatique > INRIA Paris Rocquencourt -- OCamlPro > Programming Languages and Distributed Systems > --20cf301fb60da176e504feff6132 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's not possible to create a generic "list of ar= ray" that behave almost like a list, with a chunk with a nice size (4K= B ?)


2014-07-24 18:44 GMT+02:00 Fabrice Le Fessant <Fabrice.Le_fessa= nt@inria.fr>:
Well, it is hard to enumera= te. 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 k= now the final size you need, you will finish either pre-allocating longer a= rrays than you need, or re-allocating arrays too often, or switching betwee= n lists and arrays... In the end, it really depends on what an application = does.=C2=A0

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

--Fabrice

On Thu, Jul 24, 2014 at 5:39 PM, Malcolm M= atalka <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 Fes= sant" <Fabrice.Le_fessant@inria.fr>:

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



--
Fabrice LE F= ESSANT
Chercheur en Informatique
INRIA Paris Rocquencourt -- OCamlPro=
Programming Languages and Distributed Systems

--20cf301fb60da176e504feff6132--