From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA03132; Fri, 14 Feb 2003 18:54:08 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA03119 for ; Fri, 14 Feb 2003 18:54:07 +0100 (MET) Received: from vishnu.inria.fr (vishnu.inria.fr [138.96.82.1]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h1EHs6P02591; Fri, 14 Feb 2003 18:54:06 +0100 (MET) Received: from sophia.inria.fr (localhost [127.0.0.1]) by vishnu.inria.fr (8.12.5/8.12.5) with ESMTP id h1EHs6ZT015485; Fri, 14 Feb 2003 18:54:06 +0100 X-Authentication-Warning: vishnu.inria.fr: Host localhost [127.0.0.1] claimed to be sophia.inria.fr Message-ID: <3E4D2D3E.5030801@sophia.inria.fr> Date: Fri, 14 Feb 2003 18:54:06 +0100 From: Pascal Zimmer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021203 X-Accept-Language: fr-FR, en MIME-Version: 1.0 To: Xavier Leroy CC: caml-list@inria.fr Subject: Re: [Caml-list] Optimizing false polymorphic local functions References: <3E4932B3.22A041D1@sophia.inria.fr> <20030213155038.A20336@pauillac.inria.fr> In-Reply-To: <20030213155038.A20336@pauillac.inria.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Many thanks for the reference. Just a last question: are there any reasons why this algorithm is not currently used in OCaml ? It does not seem very costly: as I was expecting, it is only a back-end to the classical typing algorithm, performing modifications on the type-annotated tree... Pascal Zimmer Xavier Leroy wrote: >>The other day, I ran into a significant speedup improvement. >>[...] >>Now consider the slightly different version where "loop" is forced into >>a monomorphic function: >>[...] >>On my computer in native code, the speedup is really significant: more >>than 6 times faster (OK this example was built on purpose...). The >>reason is that in the first case, the operator <= is replaced by a call >>to the internal polymorphic compare_val function, whereas is the second >>case a direct comparison between integers is performed. >> >>I suspect there are other cases in which the compiler can produce a >>better code when it knows more precisely the types involved. > > > Yes: besides comparisons, array and bigarray accesses can be compiled > more efficiently if the exact types of the data are known statically. > > >>So my question is: would it be possible to help him in this way by >>enforcing the type checker to infer a monomorphic type in such >>situations ? By "such situations", I mean: local polymorphic >>functions that are used in exactly one monomorphic setting >>afterwards. Of course, this is not desirable for global functions, >>since it may break the calculus; but for local functions, it should >>be of no harm since we know all the places where they are used, and >>it would not change the type of the wrapper, thus being transparent >>for the user... >>Any comment ? > > > The following paper formalizes exactly this idea, and gives a type > inference algorithm that avoids unecessary polymorphism like you suggest: > > http://citeseer.nj.nec.com/bjorner94minimal.html > > - Xavier Leroy > ------------------- > To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr > Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners