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.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 31CF4BC6B for ; Fri, 1 Jun 2007 12:02:37 +0200 (CEST) Received: from ipmail03.adl2.internode.on.net (ipmail03.adl2.internode.on.net [203.16.214.135]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l51A2YaK009043 for ; Fri, 1 Jun 2007 12:02:36 +0200 X-IronPort-AV: E=Sophos;i="4.16,371,1175437800"; d="scan'208";a="97637188" Received: from ppp9-14.lns1.syd7.internode.on.net (HELO [192.168.1.201]) ([59.167.9.14]) by ipmail03.adl2.internode.on.net with ESMTP; 01 Jun 2007 19:32:33 +0930 Subject: Re: [Caml-list] Comparison of OCaml and MLton for numerics From: skaller To: Richard Jones Cc: Alain Frisch , caml-list@yquem.inria.fr In-Reply-To: <20070601085340.GA29035@furbychan.cocan.org> References: <5195a210705302250u6a9e5adey4ed857480f9e5cd8@mail.gmail.com> <200705311008.16662.jon@ffconsultancy.com> <5195a210705310222p6aa8482fr70e7bf2b2b631b72@mail.gmail.com> <200705311127.28639.jon@ffconsultancy.com> <465F3E8C.10404@inria.fr> <1180660974.15528.126.camel@rosella.wigram> <465FAF0B.5060700@inria.fr> <1180685367.3417.9.camel@rosella.wigram> <20070601085340.GA29035@furbychan.cocan.org> Content-Type: text/plain Date: Fri, 01 Jun 2007 20:02:30 +1000 Message-Id: <1180692150.4140.11.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 465FEEBA.002 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 0100,:01 inlining:01 inlining:01 recursion:01 compiler:01 heap:01 sourceforge:01 garbage:01 garbage:01 closures:01 wrote:01 wrote:01 caml-list:01 inline:01 On Fri, 2007-06-01 at 09:53 +0100, Richard Jones wrote: > On Fri, Jun 01, 2007 at 06:09:27PM +1000, skaller wrote: > > But still, the algorithm is crude and I found it necessary > > to allow: > > > > fun f ... // maybe inline > > inline fun f // try REALLY HARD to inline > > noinline fun f // never inline > > Actually it's more useful to control the inlining of function when > they are applied, rather than when they are defined. I plan to implement that too. > In more general terms, it was found that turning off inlining in the > Linux kernel reduced the code size by 25%: > I bet that actually improved performance too, but unfortunately in the > article above they don't measure that. Yes, I believe that. Smaller is usually faster. However in Felix it isn't quite so simple. The 'general' method of calling a function involves: (a) call 'malloc()' to allocate heap store (b) link the store into the garbage collector (c) construct the object by binding its environment in (d) clone the object so recursion works (e) apply the object by passing its apply() method the arguments (f) later on, garbage collect the object ALL these steps are eliminated by inlining, and that also provides further optimisation opportunities. In particular, it typically reduces all non-recursive function call chains to a flat sequence of primitive monomorphic mutators. The resulting code is VERY fast. The code with all closures isn't quite so fast :) The compiler does other optimisations, these are just the extreme cases. -- John Skaller Felix, successor to C++: http://felix.sf.net