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 A3DBD7FA56 for ; Thu, 24 Jul 2014 07:58:59 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of anthony.tavener@gmail.com) identity=pra; client-ip=209.85.220.175; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="anthony.tavener@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of anthony.tavener@gmail.com designates 209.85.220.175 as permitted sender) identity=mailfrom; client-ip=209.85.220.175; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="anthony.tavener@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-vc0-f175.google.com) identity=helo; client-ip=209.85.220.175; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="postmaster@mail-vc0-f175.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoCALuf0FPRVdyvlGdsb2JhbABZg2BNCgSCdK8klRiBYYdFAYEACBYQAQEBAQcLCwkSK4QEAQEDARIRHQEbEgUGAQMBCwYFCwMXHQICIQEBEQEFAQoSBhMSEIgLAQMJCA2cb2qLKYFygxCKYAoZJwMKZIZKEQEFDo0QgikEB4J4gU4FhHEFhXODX4poggOBUoxShC0YKYUXHi8 X-IPAS-Result: AkoCALuf0FPRVdyvlGdsb2JhbABZg2BNCgSCdK8klRiBYYdFAYEACBYQAQEBAQcLCwkSK4QEAQEDARIRHQEbEgUGAQMBCwYFCwMXHQICIQEBEQEFAQoSBhMSEIgLAQMJCA2cb2qLKYFygxCKYAoZJwMKZIZKEQEFDo0QgikEB4J4gU4FhHEFhXODX4poggOBUoxShC0YKYUXHi8 X-IronPort-AV: E=Sophos;i="5.01,721,1400018400"; d="scan'208";a="72618430" Received: from mail-vc0-f175.google.com ([209.85.220.175]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 24 Jul 2014 07:58:58 +0200 Received: by mail-vc0-f175.google.com with SMTP id hu12so4055671vcb.20 for ; Wed, 23 Jul 2014 22:58:57 -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=YYmNaXgOlLqgmOgal05vXKOWVj5cuW4wwgeexxIhapc=; b=WDgmfcA0oMOruri++lCxETqKcyQFo9qViLDjdoQ+83R5MQz3LH43GCI8wFl4ky9hlj J1bk2EeVwwkgvDtbEHrJ5RsEaWL7WO8ZuKyNwO4qf5erjup3PQBIxPY8WK9M3Nz7dsti bsjv2+B5T/FKSIddEdWXm7uQ63lPPmB76i1U7z6aYOuzE98W4MrUrBW3ar3rvd7w+Yk1 axfLCPGvYk80cIAPDZRrMWEN4U9KSLyJ4Q4DjH/nAJYfb2oht3ThU1/ocuq+nYIjQj5r dfOEE4tcVeEezPJKRipMzELuBn609oeqDLO64pOkZn8OJCWahXN4dc5bOwKgfOIkFD6a bPYw== MIME-Version: 1.0 X-Received: by 10.220.122.132 with SMTP id l4mr8421343vcr.41.1406181537397; Wed, 23 Jul 2014 22:58:57 -0700 (PDT) Received: by 10.220.118.18 with HTTP; Wed, 23 Jul 2014 22:58:57 -0700 (PDT) In-Reply-To: References: <21456.19915.45180.915211@gargle.gargle.HOWL> Date: Wed, 23 Jul 2014 23:58:57 -0600 Message-ID: From: Anthony Tavener To: Malcolm Matalka Cc: Raoul Duke , caml-list Content-Type: multipart/alternative; boundary=089e0118263c06c04704feea2772 Subject: Re: [Caml-list] concurrent gc? --089e0118263c06c04704feea2772 Content-Type: text/plain; charset=UTF-8 I agree with Malcolm's experience, and my situation might be similar to yours: games -- a lot of allocations at high framerate. I'm guessing this from how evil you consider pauses to be. ;) In some circumstances I *have* experienced hitching, which did turn out to be due to GC -- but then I'd find I was creating a pathological case. You can't expect to throw a completely arbitrary workload at the GC and expect it to remain invisible. Just as with allocations by hand in C, even with sophisticated custom allocators -- you still need to use dynamic allocations wisely. Here, I think the biggest problem is when you have a GC, you lose awareness of the allocations you're triggering. I doubt I'd use OCaml to write the bulk of a leading-edge (in graphics fidelity, framerate, and scene size) FPS game engine, competing with Unreal or Crytek... but it's suitable for less intensive requirements. Then again, one might follow the approach of FFTW and use OCaml to write a generator which outputs a C-based renderer. :D On Wed, Jul 23, 2014 at 9:45 PM, Malcolm Matalka wrote: > 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 >> > --089e0118263c06c04704feea2772 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with Malcolm's experience, and my situation mi= ght be similar to yours: games -- a lot of allocations at high framerate. I= 'm guessing this from how evil you consider pauses to be. ;) In some ci= rcumstances I *have* experienced hitching, which did turn out to be due to = GC -- but then I'd find I was creating a pathological case. You can'= ;t expect to throw a completely arbitrary workload at the GC and expect it = to remain invisible. Just as with allocations by hand in C, even with sophi= sticated custom allocators -- you still need to use dynamic allocations wis= ely. Here, I think the biggest problem is when you have a GC, you lose awar= eness of the allocations you're triggering.

I doubt I'd use OCaml to write the bulk of a leadi= ng-edge (in graphics fidelity, framerate, and scene size) FPS game engine, = competing with Unreal or Crytek... but it's suitable for less intensive= requirements. Then again, one might follow the approach of FFTW and use OC= aml to write a generator which outputs a C-based renderer. :D


On Wed,= Jul 23, 2014 at 9:45 PM, Malcolm Matalka <mmatalka@gmail.com> wrote:

While it may not help you, oc= amls GC only kicks off during an allocation so you can at least construct a= n important section of code to not have a GC occur in it.=C2=A0 But I don&#= 39;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.c= om>:

> 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

--089e0118263c06c04704feea2772--