From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 20D14BC2F for ; Fri, 3 Dec 2004 09:23:00 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id iB38MxVi029742 for ; Fri, 3 Dec 2004 09:22:59 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id JAA13006 for ; Fri, 3 Dec 2004 09:22:59 +0100 (MET) Received: from will.iki.fi (will.iki.fi [217.169.64.20]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id iB38MwXL029737 for ; Fri, 3 Dec 2004 09:22:59 +0100 Received: from acerf.exomi.com (fa-3-0-0.fw.exomi.com [217.169.64.99]) by will.iki.fi (Postfix) with ESMTP id 52B4015F; Fri, 3 Dec 2004 10:22:56 +0200 (EET) Subject: Re: [Caml-list] Strange observation on polymorphic '<' From: Ville-Pertti Keinonen To: Ritesh Kumar Cc: caml-list@inria.fr In-Reply-To: <6FBBD2B0-44FC-11D9-AF66-000A95CDFBE4@cs.unc.edu> References: <9E571848-430E-11D9-AF66-000A95CDFBE4@cs.unc.edu> <281F644B-43EF-11D9-BA22-000D9345235C@inria.fr> <6FBBD2B0-44FC-11D9-AF66-000A95CDFBE4@cs.unc.edu> Content-Type: text/plain Date: Fri, 03 Dec 2004 10:22:46 +0200 Message-Id: <1102062166.666.25.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 41B02263.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 41B02262.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 kumar:01 wrote:01 compilation:01 toplevel:01 invocation:01 invocation:01 inlining:01 inlined:01 inlining:01 compilation:01 ocaml:01 ocaml:01 compiler:01 mlton:01 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.0 X-Spam-Level: On Fri, 2004-12-03 at 02:24 -0500, Ritesh Kumar wrote: > let max a b = if a>b then a else b;; > print_int (max 2 3);; > ============ > Separate compilation means that the function max should use the C call > (for the toplevel module). However, the invocation of max 2 3 shouldn't > use a direct call to the function in the same module as the invocation > is in the same module (i.e. there is opportunity to optimize it based The decision of whether to inline a function is done based on its size. You can increase the inlining level to allow for larger functions to be inlined. However, apparently inlining is currently done after deciding whether to call the polymorphic function, so it doesn't help in this case, which is definitely a missed optimization opportunity. > on the known invocation types). Secondly, does separate compilation > make that strong a sense in case of native compilation for OcaML ... > most probably not because it anyways generates a standalone executable? OCaml supports inlining across compilation units, so eliminating separate compilation probably wouldn't automatically give you any benefits. There is at least one compiler for a related language (Standard ML) that does global analysis by compiling everything at once (MLtoN). It's quite a bit more complex compared to OCaml, doesn't generate significantly faster code for common cases, and supports far fewer platforms. MLtoN does have the nice ability to support unboxed, untagged integers, though.