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 737537FA56 for ; Thu, 24 Jul 2014 05:45:42 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of mmatalka@gmail.com) identity=pra; client-ip=209.85.216.49; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="mmatalka@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of mmatalka@gmail.com designates 209.85.216.49 as permitted sender) identity=mailfrom; client-ip=209.85.216.49; receiver=mail3-smtp-sop.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 (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-qa0-f49.google.com) identity=helo; client-ip=209.85.216.49; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="postmaster@mail-qa0-f49.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4CABmB0FPRVdgxm2dsb2JhbABZg2BNCgSCdK8jlRiBYYdFAYEACBYQAQEBAQEGCwsJFCmEBAEBAwESER0BGxIFBgEDAQsGBQQHGh0CAiEBAREBBQEKEgYTEhCICwEDCQgNnGFqiyiBcoMQiloKGScDCmSGShEBBQ6NEIIpBAeCeIFOBYRvBYlRimWCA4FSjFCELRgphHo7Lw X-IPAS-Result: At4CABmB0FPRVdgxm2dsb2JhbABZg2BNCgSCdK8jlRiBYYdFAYEACBYQAQEBAQEGCwsJFCmEBAEBAwESER0BGxIFBgEDAQsGBQQHGh0CAiEBAREBBQEKEgYTEhCICwEDCQgNnGFqiyiBcoMQiloKGScDCmSGShEBBQ6NEIIpBAeCeIFOBYRvBYlRimWCA4FSjFCELRgphHo7Lw X-IronPort-AV: E=Sophos;i="5.01,721,1400018400"; d="scan'208";a="72611297" Received: from mail-qa0-f49.google.com ([209.85.216.49]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 24 Jul 2014 05:45:24 +0200 Received: by mail-qa0-f49.google.com with SMTP id dc16so2326739qab.22 for ; Wed, 23 Jul 2014 20:45:23 -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=l7Pb1dquDhK7cGsmC9QJqwaT6SM8mY2Huh6PZaao6cM=; b=DhdCf/WmKZoEXJ7xX0RsZw0plShqF99Zp54o4x7c5/PoE+T1Zc4IF0RjZiPZOPXhEx 3tE7QgnkBesS1tZCyuaFCynk0DBO+J4aIomyN5iqXMfHB8ZMbLgC5k+FWKfka/LE4e3W M6l5JRJXurKRU84Ft89mZkztnL60qG3DNJE6fB/RJkPCDFU8a5fdfaLu3aW5YylVx/CW nFZTdUe036a7TbrGhkOFwVi7glYvWit3MgbM5KLMMShdUVmTAnzP0IiEdirggPWN69PB JHBH5GCC8fIwFSE5+vnp9yVvG9wejye5XnifdIS2HrULAw7d/WlO3VAfu2InsD1Dz0GU Z7Vg== MIME-Version: 1.0 X-Received: by 10.140.21.137 with SMTP id 9mr9396179qgl.37.1406173523143; Wed, 23 Jul 2014 20:45:23 -0700 (PDT) Received: by 10.140.88.81 with HTTP; Wed, 23 Jul 2014 20:45:22 -0700 (PDT) Received: by 10.140.88.81 with HTTP; Wed, 23 Jul 2014 20:45:22 -0700 (PDT) In-Reply-To: References: <21456.19915.45180.915211@gargle.gargle.HOWL> Date: Thu, 24 Jul 2014 05:45:22 +0200 Message-ID: From: Malcolm Matalka To: Raoul Duke Cc: caml-list Content-Type: multipart/alternative; boundary=001a11c13bf056f29304fee84989 Subject: Re: [Caml-list] concurrent gc? --001a11c13bf056f29304fee84989 Content-Type: text/plain; charset=UTF-8 While it may not help you, ocamls GC only kicks off during an allocation so you can at least construct an important section of code to not have a GC occur in it. But I don't think that would help for your situation. Is your concern more general or do you have a specific situation? Ime it takes quite a but of work to cause a noticeable GC pause in ocaml. Den 24 jul 2014 02:09 skrev "Raoul Duke" : > > 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%. > > thanks! gotchya. > > I should have noted that my main concern is with pauses, not with > overall speedup. In other words: in interactive apps, pauses are > eeeeeevil. > > > For technical reasons, offloading major collections in OCaml is easier > > than offloading minor collections, so the potential benefit is less. > > I am guessing you mean that major collections just don't happen that > often, at least if people write their code in a non-pathalogical > fashion? :) > > sincerely. > > -- > 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 > --001a11c13bf056f29304fee84989 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

While it may not help you, ocamls GC only kicks off during a= n allocation so you can at least construct an important section of code to = not have a GC occur in it.=C2=A0 But I don't think that would help for = your situation.

Is your concern more general or do you have a specific situa= tion?=C2=A0 Ime it takes quite a but of work to cause a noticeable GC pause= in ocaml.

Den 24 jul 2014 02:09 skrev "Raoul Duke&quo= t; <raould@gmail.com>:
> 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%.

thanks! gotchya.

I should have noted that my main concern is with pauses, not with
overall speedup. In other words: in interactive apps, pauses are
eeeeeevil.

> For technical reasons, offloading major collections in OCaml is easier=
> than offloading minor collections, so the potential benefit is less.
I am guessing you mean that major collections just don't happen that
often, at least if people write their code in a non-pathalogical
fashion? :)

sincerely.

--
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
--001a11c13bf056f29304fee84989--