Version française
Home     About     Download     Resources     Contact us    
Browse thread
Modify macro and caml_initialize function
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: CUOQ Pascal <Pascal.CUOQ@c...>
Subject: Modify macro and caml_initialize function
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