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 concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 5C124BC6B for ; Fri, 1 Jun 2007 11:49:21 +0200 (CEST) Received: from furbychan.cocan.org (furbychan.cocan.org [80.68.91.176]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l519nKZH023668 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 1 Jun 2007 11:49:21 +0200 Received: from rich by furbychan.cocan.org with local (Exim 3.35 #1 (Debian)) id 1Hu3l0-0002R6-00; Fri, 01 Jun 2007 10:49:18 +0100 Date: Fri, 1 Jun 2007 10:49:18 +0100 To: Stephan Tolksdorf Cc: caml-list@inria.fr Subject: Re: [Caml-list] Comparison of OCaml and MLton for numerics Message-ID: <20070601094917.GA9283@furbychan.cocan.org> References: <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> <20070601085906.GA2146@furbychan.cocan.org> <465FE563.2050907@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <465FE563.2050907@gmx.de> User-Agent: Mutt/1.5.9i From: Richard Jones X-Miltered: at concorde with ID 465FEBA0.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 0200,:01 inlining:01 inlining:01 abstractions:01 compiler:01 runtime:01 wrote:01 wrote:01 behaviour:01 caml-list:01 alain:01 seems:03 comparison:04 fri:05 On Fri, Jun 01, 2007 at 11:22:43AM +0200, Stephan Tolksdorf wrote: > Richard Jones wrote: > >Another article on the same topic: > > > > http://lwn.net/Articles/82495/ > > > > 3% probably lies well in the error of margin. I find this comment much > more informative and in accordance with my experiences: > > http://lwn.net/Articles/167474/ > > Without inlining a lot of modern C++ code would be unusable slow. As > Alain said, inlining allows you to use abstractions without having to > pay the usual penalty for it. Good point. It just seems to confirm that you (or a compiler) cannot possibly do good inlining unless you have a great deal of information about the runtime behaviour of the program. Rich. -- Richard Jones Red Hat