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 PAA29937; Tue, 20 Aug 2002 15:01:56 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA29922 for caml-list@pauillac.inria.fr; Tue, 20 Aug 2002 15:01:56 +0200 (MET DST) 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 AAA17698 for ; Tue, 20 Aug 2002 00:06:22 +0200 (MET DST) Received: from wptx49.physik.uni-wuerzburg.de (wptx49.physik.uni-wuerzburg.de [132.187.40.49]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g7JM6LT23478 for ; Tue, 20 Aug 2002 00:06:21 +0200 (MET DST) Received: from wptx47.physik.uni-wuerzburg.de (wptx47.physik.uni-wuerzburg.de [132.187.40.47]) by wptx49.physik.uni-wuerzburg.de (8.10.0/8.10.0.Beta6) with ESMTP id g7JM6Kj29164; Tue, 20 Aug 2002 00:06:20 +0200 (METDST) Received: (from ohl@localhost) by wptx47.physik.uni-wuerzburg.de (8.10.0.Beta12/8.10.0.Beta12) id g7JM6KP13621; Tue, 20 Aug 2002 00:06:20 +0200 From: Thorsten Ohl Message-ID: <15713.27612.63106.168053@wptx47.physik.uni-wuerzburg.de> Date: Tue, 20 Aug 2002 00:06:20 +0200 To: caml-list@inria.fr Cc: malc Subject: [Caml-list] Specialization (was: Inlining across functors) In-Reply-To: References: <15712.63866.575444.515916@wptx47.physik.uni-wuerzburg.de> X-Mailer: VM 6.84 under Emacs 20.7.1 Reply-To: ohl@physik.uni-wuerzburg.de Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk malc writes: > With http://algol.prosalg.no/~malc/code/patches/specfun.tar.gz > (patch against 3.04) you will get this instead: > > *** Linearized code > Opt_f2_72: > A/11[%ecx] := [env/10[%ecx] + 12] > A/12[%ecx] := [A/11[%ecx]] > tailcall "Opt_f_62" R/0[%eax] > R/1[%ebx] > R/2[%ecx] Neat! > What will be specialized: frist order non-curried functors Unfortunately, the cases where my code would benefit most are all curried and or higher-order functors. E.g., I have beauties like module Tagged (Tagger : Tagger) (PT : Tuple.Poly) (Stat : Stat_Maker) (T : Topology.T with type 'a children = 'a PT.t) (P : Momentum.T) (M : Model.T) = struct ... end where the signature Momentum.T can be implemented by simple bitmask operations and since it is used _very_ often, specialization would help a great deal. The situation for symoblic algebra is similar. I guess that the major obstacle for generalizing your approach to specialization is in preventing code bloat. Or am I wrong? Fine-grained control for specialization (like your syntax extension) at the point of functor application would be very useful. The above code could probably gain a constant factor larger than 10, if I could specialize curried and higher-order functors. [At crunch time, I can do this by hand of course, but--also for educational reasons--it would be nice to let the compiler take care of this.] Cheers, -Thorsten -- Thorsten Ohl, Physics Dept., Wuerzburg Univ. -- ohl@physik.uni-wuerzburg.de http://theorie.physik.uni-wuerzburg.de/~ohl/ [<=== PGP public key here] ------------------- 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