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=1.3 required=5.0 tests=SPF_FAIL 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 343A5BC6E for ; Fri, 1 Jun 2007 11:22:50 +0200 (CEST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l519Mn5T030716 for ; Fri, 1 Jun 2007 11:22:49 +0200 Received: (qmail 22739 invoked from network); 1 Jun 2007 09:22:48 -0000 Received: from unknown (HELO [192.168.1.11]) ([pbs]910386@[87.122.144.122]) (envelope-sender ) by smtprelay01.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 1 Jun 2007 09:22:48 -0000 Message-ID: <465FE563.2050907@gmx.de> Date: Fri, 01 Jun 2007 11:22:43 +0200 From: Stephan Tolksdorf User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.0.7) Gecko/20060909 Thunderbird/1.5.0.7 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Richard Jones Cc: caml-list@inria.fr Subject: Re: [Caml-list] Comparison of OCaml and MLton for numerics 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> <20070601085906.GA2146@furbychan.cocan.org> In-Reply-To: <20070601085906.GA2146@furbychan.cocan.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 465FE569.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 inlining:01 inlining:01 abstractions:01 wrote:01 caml-list:01 alain:01 comparison:04 margin:94 usual:06 probably:07 unusable:07 error:12 mlton:13 slow:13 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. Regards, Stephan