From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=AWL autolearn=disabled version=3.1.3 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 726DBBBC4 for ; Tue, 31 Mar 2009 02:30:07 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAAHkA0UnUnwdkiGdsb2JhbACCIZNhAQEBCgkKCRAFpj0IjX2CQQiBMQY X-IronPort-AV: E=Sophos;i="4.38,449,1233529200"; d="scan'208";a="37531024" Received: from relay.pcl-ipout02.plus.net ([212.159.7.100]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 31 Mar 2009 02:30:07 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAGACIB0UnUnw6U/2dsb2JhbACCIbpSCI1+gkEIgTEG Received: from fhw-relay07.plus.net ([212.159.14.148]) by relay.pcl-ipout02.plus.net with ESMTP; 31 Mar 2009 01:30:06 +0100 Received: from [87.115.145.18] (helo=leper.local) by fhw-relay07.plus.net with esmtp (Exim) id 1LoRrh-0002ct-0M for caml-list@yquem.inria.fr; Tue, 31 Mar 2009 01:30:05 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Google summer of Code proposal Date: Tue, 31 Mar 2009 01:36:16 +0100 User-Agent: KMail/1.9.9 References: <200903211439.47107.cdome@bk.ru> <49C79A54.5020406@inria.fr> In-Reply-To: <49C79A54.5020406@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903310136.16374.jon@ffconsultancy.com> X-Plusnet-Relay: c0ee3546f93cf341e50b501e694e85ee X-Spam: no; 0.00; incorrectly:01 ocaml:01 2009:98 2009:98 frog:98 wrote:01 stack:01 stack:01 caml-list:01 optimization:03 stacks:03 benchmark:04 scope:04 xavier:06 interface:06 On Monday 23 March 2009 14:19:00 Xavier Leroy wrote: > "But shadow stacks are the only way to go for GC interface!" > No, it's probably the worst approach performance-wise; even a > conservative GC should work better. I blogged a quick analysis of the performance of HLVM's current shadow stack code: http://flyingfrogblog.blogspot.com/2009/03/current-shadow-stack-overheads-in-hlvm.html There is a lot of scope for optimization but these results were enlightening to show where the effort should be put. In particular, shadow stack updates by the mutator (and not the collector, as I had incorrectly assumed) account for the entire performance difference between OCaml and HLVM on the 10-queens benchmark. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e