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 PAA21136; Thu, 13 Feb 2003 15:50:42 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 PAA20465 for ; Thu, 13 Feb 2003 15:50:41 +0100 (MET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h1DEodf16315; Thu, 13 Feb 2003 15:50:40 +0100 (MET) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA20978; Thu, 13 Feb 2003 15:50:38 +0100 (MET) Date: Thu, 13 Feb 2003 15:50:38 +0100 From: Xavier Leroy To: Pascal Zimmer Cc: caml-list@inria.fr Subject: Re: [Caml-list] Optimizing false polymorphic local functions Message-ID: <20030213155038.A20336@pauillac.inria.fr> References: <3E4932B3.22A041D1@sophia.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3E4932B3.22A041D1@sophia.inria.fr>; from Pascal.Zimmer@sophia.inria.fr on Tue, Feb 11, 2003 at 06:28:19PM +0100 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > 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