Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

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: 2002-08-20 (13:01)
From: Thorsten Ohl <ohl@p...>
Subject: [Caml-list] Specialization (was: Inlining across functors)
malc  <> writes:

> With 
> (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]   


> 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) =

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.]

Thorsten Ohl, Physics Dept., Wuerzburg Univ. --     [<=== PGP public key here]
To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: