On Nov 19, 2010, at 11:02 , Fabrice Le Fessant wrote: > Benedikt Meurer wrote, On 11/19/2010 06:29 AM: >> This is indeed very interesting. I haven't thought of the native top-level. >> I haven't done any measurements yet, but from my experience with ocamlopt, I >> know that the optimizing native compiler is somewhat slower than the >> byte-code compiler. I doubt that this is related solely to the external >> as/ld invocations, so there's certainly more work to do than just replacing >> the calls to as/ld with an in-process assembler/linker. > > Indeed, there are some more passes in ocamlopt than in ocamlc, but I > think that most of the time is spent in allocating registers and > generating the assembler file and calling the assembler. As Alain said, > we already have the inline assembler, so the next step would be to > improve register allocation, either by spilling more variables to avoid > the quadratic behavior of graph coloring, either by using some linear > scan algorithm (for example, the one of HotSpot).
Using the linear scan algorithm with ocamlopt might be a good idea, due to the structure of the generated code, linear scan should give results close to that of the graph coloring algorithm for the generated native code. I'll see if I can hire some students to evaluate an implementation of linear scan for ocamlopt. > --Fabrice Benedikt _______________________________________________ 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
