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.0 required=5.0 tests=AWL,INFO_TLD 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 23BE7BC0B for ; Sat, 9 Dec 2006 01:08:07 +0100 (CET) Received: from 26.mail-out.ovh.net (26.mail-out.ovh.net [213.186.42.179]) by concorde.inria.fr (8.13.6/8.13.6) with SMTP id kB90863q021287 for ; Sat, 9 Dec 2006 01:08:06 +0100 Received: (qmail 428 invoked by uid 503); 9 Dec 2006 00:08:14 -0000 Received: (QMFILT: 1.0); 09 Dec 2006 00:08:14 -0000 Received: from b7.ovh.net (HELO mail157.ha.ovh.net) (213.186.33.57) by 26.mail-out.ovh.net with SMTP; 9 Dec 2006 00:08:14 -0000 Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 9 Dec 2006 00:08:10 -0000 Received: from vil93-4-82-227-140-227.fbx.proxad.net (HELO ?192.168.1.2?) (lists%philippewang.info@82.227.140.227) by ns0.ovh.net with SMTP; 9 Dec 2006 00:08:07 -0000 Message-ID: <4579FE5D.1000002@philippewang.info> Date: Sat, 09 Dec 2006 01:07:57 +0100 From: Philippe Wang User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Jim Grundy , caml-list@inria.fr Subject: Re: [Caml-list] A Question About Types and Inlining References: <4579F1A4.6080606@ichips.intel.com> <4579F655.3030307@philippewang.info> <4579F8E1.6070604@ichips.intel.com> In-Reply-To: <4579F8E1.6070604@ichips.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Remote: 82.227.140.227 (vil93-4-82-227-140-227.fbx.proxad.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Miltered: at concorde with ID 4579FE66.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; inlining:01 compiler:01 checker:01 compiler:01 integers:01 explicitely:01 optimise:01 cheers:01 foo:01 implements:01 foo:01 mli:01 mli:01 inlining:01 unboxed:01 Hi. Ok I misread a line... I saw once that there were a lot of optimizations based on types informations, especially on basic types... So hidding some type information would lead to prevent the compiler from some optimization... Well, I wonder about how to hide the information from the users without hiding it to the type checker... Typically the function compare (or other comparison operators) have to check the kinds of their arguments, except when the compiler knows that their types are basic types... Well, I guess you use a lot the function compare ? Have you tried to force the polymorphic functions' types that are only used with integers with the type int ? (to take back the performance, you will have to tell explicitely the compiler to optimise them... or change the compiler code... I guess.) Cheers, Philippe Wang. Jim Grundy a écrit : > Hi Philippe > > Thanks for the mail. That's not quite what I'm looking for: > > I have some module Foo, that implements a type, lets call it abs, that I > would like to keep abstract as far as the other modules are concerned. > > In foo.mli I have > > type abs > > and in foo.ml I have > > type abs = int > > (which is the set up you were recommending, right) > > But... if I change foo.mli to reveal the type to other modules, that is > if foo.mli also says > > type abs = int > > then the program runs 36% faster. > > I suspect that hiding the type is either preventing inlining of calls > from other modules to functions in the foo module, or that hiding the > type is forcing the other modules to use a boxed representation rather > than an unboxed representation. > > All the best > > Jim > > Philippe Wang wrote: >> Hi. >> >> If I have understood what you meant : >> >> Create a .mli file where you put >> type variable >> >> and in the .ml file, put >> type variable = int >> >> >> It should do what you want (i.e. tell the compiler that the actual >> type is int and not allow unifying int type with variable type elsewhere) >> >> Note : ocamlopt -i yourmlfile.ml prints the default .mli >> So you can generate the default .mli easily (at least on unix or cygwin) >> >> Cheers, >> Philippe Wang >> mail@philippewang.info >> >> >> >> Jim Grundy a écrit : >>> Apologies in advance for a naive question... >>> >>> I'm working on a SAT solver in OCaml. The solver has various types, >>> like three-valued bools, variables, literals. I have modules that >>> encapsulate these types and the operations on them. >>> >>> Now, as it turns out, all these types are represented as ints, but >>> the other modules that use those types don't need to know that - and >>> as a matter of taste I'd rather not expose this. >>> >>> The signatures of these modules currently contain lines like this: >>> >>> type variable (* = int *) >>> >>> If I uncomment all instances of (* = int *) and reveal the >>> representation to the compiler then I get a ... 36% performance >>> improvement in the SAT solver. >>> >>> I have two questions: >>> >>> 1/ Is there some way I can reveal this representation to the parts of >>> the system that clearly need it for effective optimization, without >>> opening this up for general use. >>> >>> 2/ Failing that, has someone got a pleasant method of doing >>> conditional compilation so that I can switch these comments on and >>> off with ease? >>> >>> I'm using version 3.09.2 of ocamlopt. >>> >>> Thanks in advance >>> >>> Jim >>> >>> >