Le 13/03/2012 23:46, Gerd Stolpmann a écrit :
>> ocamldebug /usr/bin/ocamlduceopt -c big_ocamlduce_module.ml
>> run
>> ... wait about two minutes and press control-C
>>
>> You will probably find the compiler executing a function from modules
>> such as Interf, Coloring or Spill, or a lower level function called
>> from these modules.
> This was also my observation.
>
>> I have never observed anything similar in OCaml, but ocamlduceopt
>> appears to use unmodified ocamlopt code generation modules. I wonder
>> what is the critical difference between OCamlDuce code and typical
>> OCaml code at this level.
> I guess the only difference is the length of the code passed at once to
> the backend, since you can generate code showing this problem for standard
> ocamlopt, as in my Hydro case.
>
I had a similar case where (handwritten) code took a long time to do
register allocation.
After looking more closely it seems that all declarations in modules
have effects that
interfere: in the coloring graph, every vertex corresponding to the
effect of affecting
the function to the field of the module has an edge to every other such
vertex. Since
the graph is represented by a set of edges, it is something like a
n².log(n) complexity
for creating the graph.
Notice that it doesn't occur for values declared at toplevel.
A simple trick to circumvent that is to split the module in submodules
and include
them later.
module M = struct
let a1 x = x
...
let an x = x
let b1 x = x
...
let bn x = x
...
end
is replaced by
module M = struct
module A = struct
let a1 x = x
...
let an x = x
end
module B = struct
let b1 x = x
...
let bn x = x
end
...
include A
include B
...
end
--
Pierre
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
