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 F16687FA4D for ; Mon, 28 Jul 2014 13:20:43 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=pra; client-ip=212.227.15.14; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=mailfrom; client-ip=212.227.15.14; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.web.de) identity=helo; client-ip=212.227.15.14; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="postmaster@mout.web.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuoBAEcx1lPU4w8OnGdsb2JhbABZ0gqFaAGBFBYQAQEBAQEGDQkJFCmEBAEFOk8LGAklDwUoiGEBGLVJH4dJF4l/hVQWgxmBGwEEm0uHBxOQfoFtJA X-IPAS-Result: AuoBAEcx1lPU4w8OnGdsb2JhbABZ0gqFaAGBFBYQAQEBAQEGDQkJFCmEBAEFOk8LGAklDwUoiGEBGLVJH4dJF4l/hVQWgxmBGwEEm0uHBxOQfoFtJA X-IronPort-AV: E=Sophos;i="5.01,748,1400018400"; d="scan'208";a="73054980" Received: from mout.web.de ([212.227.15.14]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jul 2014 13:20:43 +0200 Received: from frosties.localnet ([78.43.112.61]) by smtp.web.de (mrweb001) with ESMTPSA (Nemesis) id 0MDxWR-1XGuSU45Lr-00HKPg for ; Mon, 28 Jul 2014 13:20:42 +0200 Received: from mrvn by frosties.localnet with local (Exim 4.82) (envelope-from ) id 1XBiyt-0007PK-3X for caml-list@inria.fr; Mon, 28 Jul 2014 13:20:39 +0200 Date: Mon, 28 Jul 2014 13:20:39 +0200 From: Goswin von Brederlow To: caml-list@inria.fr Message-ID: <20140728112038.GB26816@frosties> References: <21456.19915.45180.915211@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Provags-ID: V03:K0:K7yXivVVus6ZDWVlq+E+iJpLW+GJjVh5QxPbwxgc+xyWQgqd5qJ FtCQleb7yI1NjcrQKf0CnP8Fd5pFl2akXvqjMR0DFhsEdhbg5xEF2RYaU+FYS9bhicU1Pap J+zgW/s4/+KZwNoVmy80u3bQi5iHC2Ty3/6bOC016EEHumJcDz2v3TtovIdQeNPjnZMFdn3 LiLVpu/mbqBe1HPWYgdOA== Subject: Re: [Caml-list] concurrent gc? On Wed, Jul 23, 2014 at 11:58:57PM -0600, Anthony Tavener wrote: > 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 Actually what you need to do there is to trigger the GC explicitly inbetween frames and fine tune the GC so it doesn't run mid-frame at all (make the minor heap large enough). That also tends to improve the GC efficiency since for a frame you will have lots of temporary allocations that won't outlive the frame. So at the end of each frame is the best time to clean up the minor heap. MfG Goswin