On Sep 11, 2004, at 16:36, Jon Harrop wrote:

> On Friday 10 September 2004 06:56, Christophe Raffalli wrote:
>> You could also lie in the tag about the size of array (if the way the
>> runtime finds free block of memory does not use it). It will cost an
>> increment of integer at each step in the initialisation process which
>> should not be much since the beginning of array may stay in the cache 
>> if
>> the initialisation function is simple and this will be neggligeable 
>> if not.
>
> What is the trickiest/most-error-prone part of doing this and could 
> this be
> used to implement amortised extensible arrays within the compiler? I 
> would
> like to see such a thing in the compiler (not that I distrust Markus 
> ;-).

The "if" part is false...  I suppose it might be possible to change
representations (true length in header and initialized part stored 
off-line /
initialized part in header / true length off-line) when the GC switches
between sweeping and marking.  We would also need several additional
primitives to create, update, and destroy the "off-line" part.  Frankly,
I find it hard to imagine that it would give a noticeable run-time
improvement on any program.  Most likely, it would make them all a 
fraction
of a percent slower, except for the most synthetic of benchmarks.

> On Friday 10 September 2004 14:45, Damien Doligez wrote:
>> An intermediate solution would
>> be to make a "Array.unsafe_make" primitive, which would use memset
>> instead of initialising the array properly.  If you enter this as
>> a feature wish in the BTS, I'll look into it.
>
> No, I don't think the performance improvement would justify your time 
> or the
> loss of safety.

No loss of safety if we don't export that primitive and use it only in
Array.init.  After all, it only breaks type safety, and only if you use
it wrong.

>  Could you add a memset to String.create though? :-)

String.make

> An array_init2 function which specialises the array type but uses an 
> external
> "f" function betters the time taken by Array.init by ~36% (perhaps not
> significantly different):

That's from getting rid of the float/non-float test.  Nothing to do with
the cost of initializing twice.

-- Damien

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners