ygrek wrote: > BTW, while we are on this topic, why the following is not in upstream yet? > > http://eigenclass.org/R2/writings/optimizing-caml_modify > > Looks like a clear win-win without drawbacks (increased code size shouldn't > be significant > cause Modify is only used in a couple of places). What do you think?
This is very interesting. Thanks for pointing it out. I think there would be a couple of alternatives to check out before calling the patch final (and even so, it may always remain an outside patch, depending on interest from OCaml maintainers). Contrary to what is implied in that post, Array.make does not call the Modify macro: it calls the caml_initialize function. If you want to make Array.make faster, there is a simple improvement: replace the idiom below: for (i = 0; i < size; i++) caml_initialize(&Field(res, i), init); by a call to a single function caml_initialize_block that factors the computation of the condition: (Is_block (val) && Is_young (val) && Is_in_heap (fp)). A quick "grep -3 caml_initialize byterun/*.c" reveals 4 (out of 5) call sites that could benefit from the caml_initialize_block function. In fact, this makes me wonder if, in the case of Array.map, Array.init and so on, a workable approach could not be to compute a few values at a time (saving them in local roots) and write them all at once, again factoring the tests Is_in_heap (fp) and caml_gc_phase == Phase_mark The first suggestion seems to me an uniform improvement with no downside, and it stands a slim chance of going in someday. The second one, no so much, but it would definitely be fun to try to make work. Pascal _______________________________________________ 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
