caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* Functor Performace Question
@ 2007-04-10 22:15 Jim Grundy
  2007-04-10 22:37 ` [Caml-list] " Till Varoquaux
  2007-04-22 10:04 ` Xavier Leroy
  0 siblings, 2 replies; 3+ messages in thread
From: Jim Grundy @ 2007-04-10 22:15 UTC (permalink / raw)
  To: caml-list

I have a functor related performance issue.

I have the following collection of modules and types that we are using 
in the implementation of a SAT solver:

module type Map = sig .. end

module Nat_map: Map with type key = int

module type PriorityQueue = sig .. end

module Make_priority_queue:
   functor (M : Map) -> PriorityQueue with type elt = M.key

module Nat_priority_queue: PriorityQueue  with type elt = int

If we implement Nat_priority_queue in the "right" way as

module Nat_priority_queue = Make_priority_queue (Nat_map)

Then I pay about a 3% performance penalty over instantiating the functor 
by hand...

module Nat_priority_queue  = struct
   module M = Nat_map
   (* same code as the body of Make_priority_queue *)
end

Is there some compiler switch or future version in the works that will 
save me from this?

Thanks

Jim


-- 
Jim Grundy, Research Scientist. Intel Corporation, Strategic CAD Labs
Mail Stop RA2-451, 2501 NW 229th Ave, Hillsboro, OR 97124-5503, USA
Phone: +1 971 214-1709   Fax: +1 971 214-1771
http://www.intel.com/technology/techresearch/people/bios/grundy_j.htm
Key Fingerprint: 5F8B 8EEC 9355 839C D777  4D42 404A 492A AEF6 15E2


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Caml-list] Functor Performace Question
  2007-04-10 22:15 Functor Performace Question Jim Grundy
@ 2007-04-10 22:37 ` Till Varoquaux
  2007-04-22 10:04 ` Xavier Leroy
  1 sibling, 0 replies; 3+ messages in thread
From: Till Varoquaux @ 2007-04-10 22:37 UTC (permalink / raw)
  To: Jim Grundy; +Cc: caml-list

Functors are computed at run time... defunctorisation has been studied
for Ocaml before [1], however the current implementation of reccursive
modules relies on these modules not being defunctorised (The process
is being made in a lazy like way at runtime since fix point cannot
always be reached during compilation).

Like monorphisation defunctorisation is a whole program optimization
technique that relies on the existence of a finite number of cases.
However ocaml is not about whole program optimizations nor are we
dealing with finite universes (in the general case, although more than
90% of the ocaml programs don't uses these corner cases). I doubt we
will see these in a caml compiler any time soon.

Till

P.S.: You should take my answer with a grain of salt: I'm not
affiliated in anyways with ocaml development team.

[1]http://www.lri.fr/~signoles/publis/signoles06defun.ps.gz

On 4/11/07, Jim Grundy <jim.d.grundy@intel.com> wrote:
> I have a functor related performance issue.
>
> I have the following collection of modules and types that we are using
> in the implementation of a SAT solver:
>
> module type Map = sig .. end
>
> module Nat_map: Map with type key = int
>
> module type PriorityQueue = sig .. end
>
> module Make_priority_queue:
>    functor (M : Map) -> PriorityQueue with type elt = M.key
>
> module Nat_priority_queue: PriorityQueue  with type elt = int
>
> If we implement Nat_priority_queue in the "right" way as
>
> module Nat_priority_queue = Make_priority_queue (Nat_map)
>
> Then I pay about a 3% performance penalty over instantiating the functor
> by hand...
>
> module Nat_priority_queue  = struct
>    module M = Nat_map
>    (* same code as the body of Make_priority_queue *)
> end
>
> Is there some compiler switch or future version in the works that will
> save me from this?
>
> Thanks
>
> Jim
>
>
> --
> Jim Grundy, Research Scientist. Intel Corporation, Strategic CAD Labs
> Mail Stop RA2-451, 2501 NW 229th Ave, Hillsboro, OR 97124-5503, USA
> Phone: +1 971 214-1709   Fax: +1 971 214-1771
> http://www.intel.com/technology/techresearch/people/bios/grundy_j.htm
> Key Fingerprint: 5F8B 8EEC 9355 839C D777  4D42 404A 492A AEF6 15E2
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Caml-list] Functor Performace Question
  2007-04-10 22:15 Functor Performace Question Jim Grundy
  2007-04-10 22:37 ` [Caml-list] " Till Varoquaux
@ 2007-04-22 10:04 ` Xavier Leroy
  1 sibling, 0 replies; 3+ messages in thread
From: Xavier Leroy @ 2007-04-22 10:04 UTC (permalink / raw)
  To: Jim Grundy; +Cc: caml-list

> I have a functor related performance issue.
> I have the following collection of modules and types that we are using
> in the implementation of a SAT solver:
> If we implement Nat_priority_queue in the "right" way as
> module Nat_priority_queue = Make_priority_queue (Nat_map)
> Then I pay about a 3% performance penalty over instantiating the functor
> by hand...
> Is there some compiler switch or future version in the works that will
> save me from this?

Basically, no.  There is indeed a small performance penalty associated
with functors, owing to the fact that the functor body is compiled
only once without knowledge of its arguments.  Late specialization of
functors would be nice in the absolute, but would require a major
rework of the OCaml compiler.  This said, a 3% speed penalty is not
too bad --- to me, it's lost in the noise of performance measurement.

Regards,

- Xavier Leroy


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2007-04-22 10:04 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-04-10 22:15 Functor Performace Question Jim Grundy
2007-04-10 22:37 ` [Caml-list] " Till Varoquaux
2007-04-22 10:04 ` Xavier Leroy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).