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=AWL 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 A70BBBC69 for ; Fri, 1 Jun 2007 10:53:50 +0200 (CEST) Received: from furbychan.cocan.org (furbychan.cocan.org [80.68.91.176]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l518rog5023024 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 1 Jun 2007 10:53:50 +0200 Received: from rich by furbychan.cocan.org with local (Exim 3.35 #1 (Debian)) id 1Hu2tB-0000XP-00; Fri, 01 Jun 2007 09:53:41 +0100 Date: Fri, 1 Jun 2007 09:53:41 +0100 To: skaller Cc: Alain Frisch , caml-list@yquem.inria.fr Subject: Re: [Caml-list] Comparison of OCaml and MLton for numerics Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1180685367.3417.9.camel@rosella.wigram> User-Agent: Mutt/1.5.9i From: Richard Jones X-Miltered: at discorde with ID 465FDE9E.002 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 inlining:01 inlined:01 inlined:01 trivial:01 inlining:01 wrote:01 caml-list:01 inline:01 inline:01 kernel:01 algorithm:01 defined:02 comparison:04 applied:04 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. You probably only want f to be inlined in a few known places, and not inlined the rest of the time (unless f is extremely trivial). In more general terms, it was found that turning off inlining in the Linux kernel reduced the code size by 25%: http://lwn.net/Articles/166172/ I bet that actually improved performance too, but unfortunately in the article above they don't measure that. Rich. -- Richard Jones Red Hat