From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 2C1C0BBAF for ; Sat, 5 Dec 2009 18:35:44 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEAAJIoGkvUGyoGkWdsb2JhbACZEIJeAQEBAQkLCgcTA7huhDMEgWeLPQ X-IronPort-AV: E=Sophos;i="4.47,347,1257116400"; d="scan'208";a="51562582" Received: from smtp6-g21.free.fr ([212.27.42.6]) by mail4-smtp-sop.national.inria.fr with ESMTP; 05 Dec 2009 18:35:43 +0100 Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id B2D3DE08087; Sat, 5 Dec 2009 18:35:37 +0100 (CET) Received: from [192.168.1.3] (che78-2-82-237-71-191.fbx.proxad.net [82.237.71.191]) by smtp6-g21.free.fr (Postfix) with ESMTP id C25FDE081B5; Sat, 5 Dec 2009 18:35:34 +0100 (CET) Message-ID: <4B1A99E6.8080008@inria.fr> Date: Sat, 05 Dec 2009 18:35:34 +0100 From: Xavier Leroy User-Agent: Thunderbird 2.0.0.23 (X11/20091009) MIME-Version: 1.0 To: Aaron Bohannon Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Gc.compact surprisingly helpful References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; inserting:01 compactions:01 damien:01 compactor:01 orthogonal:01 inserting:01 300%:98 wrote:01 compilers:01 heap:01 caml-list:01 33%:97 binary:02 external:03 bytes:03 Aaron Bohannon wrote: > In order to prevent irregular GC pauses, I decided to try inserting > a call to Gc.compact once per loop. I was hoping the overall > throughput wouldn't suffer too badly. To my very pleasant surprise, > I found the throughput *increased* by about 2%!! So in a 15 second > run (with no idle time, as I said), it now does about 130 heap > compactions instead of 3 and gets better total performance because > of it, utterly defying my GC intuition. As Damien said, maybe the original code ran into a bad case of free list fragmentation which the compactor cured. But maybe the 2% is just measurement noise. Some of my favorite horror stories about timings: http://www-plan.cs.colorado.edu/diwan/asplos09.pdf "We see that something external and orthogonal to the program, i.e., changing the size (in bytes) of an unused environment variable, can dramatically (frequently by about 33% and once by almost 300%) change the performance of our program." http://compilers.iecc.com/comparch/article/96-02-165 [ Execution speed for the same binary varies by a factor of 2 depending on cache placement ] I have also personally observed speed differences of 20% just from inserting or deleting dead code in a program... - Xavier Leroy