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,HTML_MESSAGE 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 DED86BC69 for ; Fri, 1 Jun 2007 17:58:17 +0200 (CEST) Received: from smtp.janestcapital.com (www.janestcapital.com [66.155.124.107]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l51FwGT6018383 for ; Fri, 1 Jun 2007 17:58:17 +0200 Received: from [172.25.129.161] [38.96.172.125] by janestcapital.com with ESMTP (SMTPD-9.10) id A2230388; Fri, 01 Jun 2007 11:58:27 -0400 Message-ID: <46604214.8020408@janestcapital.com> Date: Fri, 01 Jun 2007 11:58:12 -0400 From: Brian Hurt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alain Frisch Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Comparison of OCaml and MLton for numerics References: <5195a210705302250u6a9e5adey4ed857480f9e5cd8@mail.gmail.com> <891bd3390706010429g2ac722bfmc6932b15393a62b9@mail.gmail.com> <20070601214326.e0a939a6.mle+ocaml@mega-nerd.com> <200706011258.59177.jon@ffconsultancy.com> <604682010706010718x42221e8rde56317905f5c972@mail.gmail.com> <466033EC.3050909@janestcapital.com> <46603DFE.7020406@inria.fr> In-Reply-To: <46603DFE.7020406@inria.fr> Content-Type: multipart/alternative; boundary="------------030101060405080303020406" X-Miltered: at discorde with ID 46604218.002 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 frisch:01 inlining:01 ocaml:01 pervasives:01 inlining:01 compiler:01 computed:01 abstraction:01 inlined:01 inlined:01 recursive:01 skipping:01 frisch:01 pervasives:01 This is a multi-part message in MIME format. --------------030101060405080303020406 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Alain Frisch wrote: >Brian Hurt wrote: > > >>where the function is only called from one place, or 3) where inlining >>opened up signifigant other optimization opportunities. The classic >>example for Ocaml here is replacing a call to Pervasives.compare with an >>integer compare. Most of the rest of the time, inlining is either a >>break even proposition, or often a loss. >> >> > >Another good situation is when inlining allows the compiler to turn a >function call to an unknown location into a direct function call (or no >function call at all). This happens as soon as you write "List.map (fun >x -> ...)". Inlining List.map would avoid the allocation of the closure >and a computed call (and then the local abstraction will also be inlined >in the body of the inlined List.map because it is used only once). >Currently, OCaml never inlines recursive functions. > > > This qualifies as an optimization opportunity- turning a call to caml_apply into a direct function call is an optimization. Which may open up other optimization possibilities. But that was my point- if the only thing you're getting out of inlining a function is skipping a function call (to a known location), then inlining generally isn't worth it- it's only worth it if it opens up other possibilities. Brian --------------030101060405080303020406 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Alain Frisch wrote:

Brian Hurt wrote:

where the function is only called from one place, or 3) where inlining
opened up signifigant other optimization opportunities.  The classic
example for Ocaml here is replacing a call to Pervasives.compare with an
integer compare.  Most of the rest of the time, inlining is either a
break even proposition, or often a loss.


Another good situation is when inlining allows the compiler to turn a
function call to an unknown location into a direct function call (or no
function call at all). This happens as soon as you write "List.map (fun
x -> ...)". Inlining List.map would avoid the allocation of the closure
and a computed call (and then the local abstraction will also be inlined
in the body of the inlined List.map because it is used only once).
Currently, OCaml never inlines recursive functions.

This qualifies as an optimization opportunity- turning a call to caml_apply into a direct function call is an optimization. Which may open up other optimization possibilities. But that was my point- if the only thing you're getting out of inlining a function is skipping a function call (to a known location), then inlining generally isn't worth it- it's only worth it if it opens up other possibilities.

Brian

--------------030101060405080303020406--