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 A2C66BBAF for ; Mon, 22 Nov 2010 19:33:40 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYBACtG6kzRVdQ0kGdsb2JhbACDSp8PCBUBAQEBCQkMBxEDH6NEiSc8ghiFKy6IWQEBAwWBHYM2cwSOUoIJ X-IronPort-AV: E=Sophos;i="4.59,237,1288566000"; d="scan'208";a="79991842" Received: from mail-vw0-f52.google.com ([209.85.212.52]) by mail4-smtp-sop.national.inria.fr with ESMTP; 22 Nov 2010 19:33:40 +0100 Received: by vws3 with SMTP id 3so3666527vws.39 for ; Mon, 22 Nov 2010 10:33:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=hQ5pp5/3Xkyquf1cZUAOfJ0aElcPQ1xi5j3fLfdaz1g=; b=HgracWr1qZynlBPro4kBbVgmFKVUqFPkaf4Sl8fR9o/SeoGyJSGgk+W1+aNatPb29Z EE4I1RZagh7HQMe+REo621qnloZczuh2rVWYSH0PgRqKxqUTORTi/pkyKcg4w9Ud8cIr ssV9KQisuFmGqsr0fvsaKp76RbwIO+bPICrfo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=RQUO6MCrjsqGtIi5WGQNYGUld0JOJaPJ6fB2UnKM1jiXRPgmb4wDu3Hk+7S3D4S73V oRjJKIEIMYxySBzW0LxGJXTHSkJi4Vzi/abV6xhYvFrBVzQdg+p8PAn4OBzqJf59c2Ab BUXB1NhEPbC4GcKrOX89QpZhHOTovN6n5tjjE= Received: by 10.223.102.69 with SMTP id f5mr840906fao.107.1290450818579; Mon, 22 Nov 2010 10:33:38 -0800 (PST) Received: from deb0 ([79.114.95.139]) by mx.google.com with ESMTPS id k21sm1466053faa.25.2010.11.22.10.33.37 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Nov 2010 10:33:38 -0800 (PST) Date: Mon, 22 Nov 2010 20:33:34 +0200 From: =?UTF-8?B?VMO2csO2aw==?= Edwin To: Fabrice Le Fessant Cc: bluestorm , Gerd Stolpmann , caml-list@yquem.inria.fr Subject: Re: [Caml-list] Is OCaml fast? Message-ID: <20101122203334.7adc5ee6@deb0> In-Reply-To: References: <1290434674.16005.354.camel@thinkpad> <582306206.731582.1290438133628.JavaMail.root@zmbs4.inria.fr> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.01; ocaml:01 ocaml:01 ocaml's:01 runtime:01 allocates:01 edwin:98 edwin:98 0.06:98 0.19:98 0.28:98 3.2:98 1.2:98 garbage:01 wrote:01 binaries:01 On Mon, 22 Nov 2010 17:46:49 +0100 Fabrice Le Fessant wrote: > 2010/11/22 T=C3=B6r=C3=B6k Edwin : > > Isn't it possible for the GC to realise its doing too many > > collections and increase the minor heap size on its own? >=20 > Indeed, it could notice that a lot of data is being moved to the major > heap, and double its size in consequence, until a maximum limit is > reached. I did some benchmarks on 2 CPUs, and here are the wall clock times for GC minor heap size: "minorheap"," phenomII",,," core2",,,"cycle diff %" ," time",," cycles","time",," cycles", 32," 17.76","17.74",56.8," 48.60","48.86",58.48,2.96 64," 16.81","16.80",53.78,"44.79","44.79",53.75,-0.06 128," 15.41","15.38",49.26,"41.38","40.76",49.28,0.04 256," 14.39","14.35",45.98,"39.75","38.98",47.24,2.74 512," 12.97","13.15",41.79,"35.75","35.59",42.8,2.42 1024," 12.89","12.94",41.33,"33.57","33.13",40.02,-3.17 2048," 11.05","11.09",35.42,"29.26","29.12",35.03,-1.1 4096," 9.79"," 9.81",31.36,"26.21","25.96",31.3,-0.19 8192," 8.71"," 8.85",28.1," 23.36","23.34",28.02,-0.28 16384," 7.89"," 7.86",25.2," 21.41","21.54",25.77,2.26 32768," 7.55"," 7.55",24.16,"20.74","20.88",24.97,3.35 (minorheap is in KWords, time is in seconds, cycles is divided by 10^9) Increasing minor heap beyond that yielded no improvement (number of minor heap collections stayed the same). phenomII has 64 Kb L1 data cache, 512Kb L2 cache, 6144Kb L3 cache (shared), runs at 3.2Ghz. That would be 516k words if only 1 core used. core2 has 32 Kb L1 data cache, 4MB L2 cache, runs at 1.2Ghz. That would be 840k words if only 1 core used. Both used exact same binaries on 64-bit Linux, ocaml 3.11.2. Despite the difference in CPUs and heap sizes the number of CPU cycles spent for a given size of the minor heap is about the same (within 3% difference). Not sure what the max should be for the minor heap increase, but based on this benchmark increasing size of minor heap never slows down the program. Even when size of minor heap exceeds what fits in the cache. I guess there is another microbenchmark that can show the opposite though. Is there some real world benchmark for OCaml's GC that can be used to get some better values for minor heap size based on CPU's L2/L3 size (as suggested in the 'Optimizing garbage collection' thread)? >=20 > The problem is that it is the kind of things that are application > dependent, Yes, maybe optimal size of minor heap doesn't depend on CPU's cache size but on the application, in which case a heuristic for increasing/decreasing the heap size may be better? > and should be put in the program itself (the program would > have a trigger on each minor heap collection, and, depending on the > moved bytes, would increase the size of the minor heap). The problem > is that the Shootout does not allow that, so the winner is the > language whose runtime allocates the most memory at the beginnning... If tuning minor heap can double performance of the program, then the GC should have some heuristics to tune it automatically. Sure applications which are not happy with that tuning should tune it themselves. Best regards, --Edwin