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 3BB357F30A for ; Mon, 25 Feb 2013 17:33:15 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.128.181; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.128.181 as permitted sender) identity=mailfrom; client-ip=209.85.128.181; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@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-ve0-f181.google.com) identity=helo; client-ip=209.85.128.181; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-ve0-f181.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkIABWSK1HRVYC1XWdsb2JhbABFFoZ1qE+Re30IFgMWCxMTKYIfAQEFDDQBGxILAQMMBgULDQ0hIgERAQUBCAISBhMSAgeHZQEDDwyhcIwygnuEOwoZJwMKWYgUAQUMjk8zB4NAA5J8g0GBHY1mFimEKw X-IPAS-Result: ArkIABWSK1HRVYC1XWdsb2JhbABFFoZ1qE+Re30IFgMWCxMTKYIfAQEFDDQBGxILAQMMBgULDQ0hIgERAQUBCAISBhMSAgeHZQEDDwyhcIwygnuEOwoZJwMKWYgUAQUMjk8zB4NAA5J8g0GBHY1mFimEKw X-IronPort-AV: E=Sophos;i="4.84,735,1355094000"; d="scan'208";a="4413812" Received: from mail-ve0-f181.google.com ([209.85.128.181]) by mail2-smtp-roc.national.inria.fr with ESMTP; 25 Feb 2013 17:33:13 +0100 Received: by mail-ve0-f181.google.com with SMTP id d10so2282225vea.26 for ; Mon, 25 Feb 2013 08:33:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=WApFKDam9KtqzNlyg9xf/GnNa/0S63PJBD+kpdU8CnM=; b=dz5HofU1W/xD2PChV7eb44MIR6ZZQFNrZyS4XLW0kbDM7LvncEHzJ+5xWellkJzs4P l79HnyTwfItJEB7Zpm8oDZw52n7+V76gKD7ba5SlBFLxAZZ4a+r0MEOgTdzWMz8oyMfR W9fkMJc6gIJlDXQ/Zjx5JVXAktSSjxNyF8rMfN/sWvPhfG3deOhlXvdDpNx/FQ8ozKfF Yx6FaPdGcX0xD5XwNUIe5u/qbtnCOrYo9/LIR3muOFYm28c/DvRDA5YXyx+q0b18jYmR U4BZrxL6uawWlIqnjUrsrbvzLC2kMognCf/l8+7XpqlGRCeCpE8U7UorPnEpntLG27Uv ++mA== X-Received: by 10.52.71.137 with SMTP id v9mr8823348vdu.104.1361809993201; Mon, 25 Feb 2013 08:33:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.67.168 with HTTP; Mon, 25 Feb 2013 08:32:33 -0800 (PST) In-Reply-To: <512B872B.60809@lexifi.com> References: <1361799073.2723.5@samsung> <512B872B.60809@lexifi.com> From: Gabriel Scherer Date: Mon, 25 Feb 2013 17:32:33 +0100 Message-ID: To: Alain Frisch Cc: Gerd Stolpmann , Francois Berenger , caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: AW: [Caml-list] What is triggering a lot of GC work? Thanks for the friendly poking. I did get some code (I've actually been surprised by how dedicated some submitters one, eg. Edwin T=F6r=F6k), but my plate has been full non-stop since and I haven't yet taken the time to put this into shape. It's on my TODO list and I hope to share some results in the coming weeks. Regarding the interesting battle story from Gerd, my own idea was to "oldify" the values before inserting them in the array, in order not to fire the write barrier. Oldifying values is costly as well, so I'm not sure if that's interesting if the array is long-lived but the elements short-lived. And more importantly, the oldifying interface is, to my knowledge, not exposed to end-users (while it's possible through the C interface to allocate directly in the old region), so this cannot be written and tested without ugly hacks right now. I'd still be curious to know how this solution would compare to the others. On Mon, Feb 25, 2013 at 4:45 PM, Alain Frisch wro= te: > On 02/25/2013 02:31 PM, Gerd Stolpmann wrote: >> >> This can have counter-intuitive consequences. Yesterday I sped an >> imperative program up by adding allocations! > > > This is really an interesting scenario, thanks for sharing! > > Two other approaches to addressing the same performance issue could have > been: > > 1. increase the size of the minor heap so that your array stays in it lo= ng > enough; > > 2. try to reduce the number of other allocations. > > Did you try one of these approaches as well? (1 in particular is > particularly easy to test.) > > > > Gabriel Scherer recently called the community to share representative > "benchmarks", in order to help core developers target optimization efforts > to where they are useful: > > http://gallium.inria.fr/~scherer/gagallium/we-need-a-representative-bench= mark-suite/ > > Gabriel: except from LexiFi's contribution, did you get any code? Gerd: = it > would be great if you could share the code you mention above; is it an > option? There are a number of optimizations which have been proposed > (related to boxing of floats, compilation strategy for let-binding on > tuples, etc), which could reduce significantly the allocation rate of some > programs. In my experience, this reduction can be observed on real-sized > programs, but it does not translate to noticeable speedups. It might be t= he > case that your program would benefit from such optimizations. Having acc= ess > to the code would be very useful! > > > Alain > > > -- > 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