Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] O'Caml vs C++: a little benchmark
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Thorsten Ohl <ohl@p...>
Subject: [Caml-list] Specialization (was: Inlining across functors)
malc  <malc@pulsesoft.com> 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