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 7B5B97FA56 for ; Thu, 24 Jul 2014 09:38:28 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of mmatalka@gmail.com) identity=pra; client-ip=209.85.192.54; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="mmatalka@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of mmatalka@gmail.com designates 209.85.192.54 as permitted sender) identity=mailfrom; client-ip=209.85.192.54; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="mmatalka@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-qg0-f54.google.com) identity=helo; client-ip=209.85.192.54; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="postmaster@mail-qg0-f54.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcCAG+30FPRVcA2m2dsb2JhbABZg2BXBIJ0rxiVGIFhh0UBgQIIFhABAQEBAQYLCwkUKYQEAQEDARIRHQEbEgsBAwELBgUEBxodAgIiAREBBQEKEgYTEgkHiAsBAwkIDZwoaospgXKDEIpaChknAwpkhkoRAQUOjzkEB4J4gU4FhHEFlj2BUpB/GCmEejsv X-IPAS-Result: AkcCAG+30FPRVcA2m2dsb2JhbABZg2BXBIJ0rxiVGIFhh0UBgQIIFhABAQEBAQYLCwkUKYQEAQEDARIRHQEbEgsBAwELBgUEBxodAgIiAREBBQEKEgYTEgkHiAsBAwkIDZwoaospgXKDEIpaChknAwpkhkoRAQUOjzkEB4J4gU4FhHEFlj2BUpB/GCmEejsv X-IronPort-AV: E=Sophos;i="5.01,722,1400018400"; d="scan'208";a="86763286" Received: from mail-qg0-f54.google.com ([209.85.192.54]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 24 Jul 2014 09:38:27 +0200 Received: by mail-qg0-f54.google.com with SMTP id z60so2797200qgd.13 for ; Thu, 24 Jul 2014 00:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=63JIcBIsWF9vG6mh0M5nhfO9QSqBeURAImb1aSGJVMI=; b=yAK9se0iZnXQFTPnTcaoiFMex9vhxprHb0gj4H0eqrD4JqT+QMiOElDsmWVtpjnyuo NjlGHU9HR0O5yw0Uy24Oml0f+KJLg7QLiFc7RAkIkyBUGT37HJisB0CPSKWre3VkJH+U 5MvYgRw7Yv21b7IPmVLDr3k9kv29bLqboHINgwFB359mv+7VNWHDH63MzT20YKJ7bSWB iIMN/ZIQPI6ESP3kI0CiZw0waJ8DqEIhxAhLxxoyWgS8Rbsw4LQ+eLybCfatdUYZdez3 7hnKiQJYqKJJEhOOJTZ+JJ3pC38W05Z9BbwDbOh1ctrmgfoNnjcDeG9hn3oUa4TdmvvO uMnA== MIME-Version: 1.0 X-Received: by 10.224.137.65 with SMTP id v1mr11773407qat.53.1406187506662; Thu, 24 Jul 2014 00:38:26 -0700 (PDT) Received: by 10.140.88.81 with HTTP; Thu, 24 Jul 2014 00:38:26 -0700 (PDT) Received: by 10.140.88.81 with HTTP; Thu, 24 Jul 2014 00:38:26 -0700 (PDT) In-Reply-To: References: <21456.19915.45180.915211@gargle.gargle.HOWL> Date: Thu, 24 Jul 2014 09:38:26 +0200 Message-ID: From: Malcolm Matalka To: Nicolas Boulay Cc: Raoul Duke , OCaml Content-Type: multipart/alternative; boundary=001a11c2cc30d282bc04feeb8a19 Subject: Re: [Caml-list] concurrent gc? --001a11c2cc30d282bc04feeb8a19 Content-Type: text/plain; charset=UTF-8 It's highly dependent on the situation but in my experience the goal is almost always to avoid doing a collection over all 60 gb. It's expensive no matter how you do it. Solutions include spreading the data over multiple processes and/or moving the data outside the managed heap. Ocaml-ancient is worth looking at as well. Den 24 jul 2014 09:01 skrev "Nicolas Boulay" : > 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 >> > > --001a11c2cc30d282bc04feeb8a19 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

It's highly dependent on the situation but in my experie= nce the goal is almost always to avoid doing a collection over all 60 gb.= =C2=A0 It's expensive no matter how you do it.=C2=A0 Solutions include = spreading the data over multiple processes and/or moving the data outside t= he managed heap.=C2=A0 Ocaml-ancient is worth looking at as well.

Den 24 jul 2014 09:01 skrev "Nicolas Boulay= " <nicolas@boulay.name&g= t;:
What about server that use ~60GB of RAM ? Todays serv= er are sold with 32 to 256 GB of RAM and lot of cpu core.
Maybe i= n such extreme cases, offloading the major collection of the GC could reduc= e 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

--001a11c2cc30d282bc04feeb8a19--