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=none 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 1F6FEBC76 for ; Fri, 1 Jun 2007 15:49:02 +0200 (CEST) Received: from ext.lri.fr (ext.lri.fr [129.175.15.4]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l51Dn19S013830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 1 Jun 2007 15:49:01 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by ext.lri.fr (Postfix) with ESMTP id 7D3AB2020DF; Fri, 1 Jun 2007 15:49:01 +0200 (CEST) Received: from smtp.lri.fr (serveur3-5 [129.175.3.5]) by ext.lri.fr (Postfix) with ESMTP id 519382020DD; Fri, 1 Jun 2007 15:49:01 +0200 (CEST) Received: from serveur9-10.lri.fr (serveur9-10 [129.175.9.10]) by smtp.lri.fr (Postfix) with ESMTP id 75490CED98; Fri, 1 Jun 2007 15:48:59 +0200 (CEST) Received: from localhost ([127.0.0.1] ident=signoles) by serveur9-10.lri.fr with esmtp (Exim 3.36 #1 (Debian)) id 1Hu7Uz-0006Bz-00; Fri, 01 Jun 2007 15:49:01 +0200 Date: Fri, 1 Jun 2007 15:49:00 +0200 (CEST) From: Julien Signoles To: Jon Harrop Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Comparison of OCaml and MLton for numerics In-Reply-To: <200706011258.59177.jon@ffconsultancy.com> Message-ID: References: <5195a210705302250u6a9e5adey4ed857480f9e5cd8@mail.gmail.com> <891bd3390706010429g2ac722bfmc6932b15393a62b9@mail.gmail.com> <20070601214326.e0a939a6.mle+ocaml@mega-nerd.com> <200706011258.59177.jon@ffconsultancy.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at lri.fr X-Miltered: at discorde with ID 466023CD.004 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; signoles:01 signoles:01 lri:01 ocaml:01 functor:01 functor:01 speedup:01 inlining:01 ocamlopt:01 -inline:01 lri:01 penalties:98 caml-list:01 modules:02 depends:04 > Indeed, after you defunctorize what performance penalties are left by modules? Indeed, really depends on the context ;-). If you don't use many operations which come from a functor application (compared with the number of costly operations in your application), the performance penalty of a functor application is probably not relevant. However, in some cases, defunctorization may produce a good speedup, especially if you use massive inlining (e.g. ocamlopt -inline 1000). On the contrary, defunctorization may produce cache problem because the size of the defunctorized code may be very bigger than the size of the initial code. Julien -- mailto:Julien.Signoles@lri.fr ; http://www.lri.fr/~signoles "In theory, practice and theory are the same, but in practice they are different" (Larry McVoy)