Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Gripes with array
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jon Harrop <jon@j...>
Subject: Re: [Caml-list] Gripes with array
On Friday 10 September 2004 14:45, Damien Doligez wrote:
> Not without implementing such horrors as Christophe described.  I don't
> much
> like the idea of introducing lots of bugs while slowing down the whole
> GC,
> even for programs that don't use arrays.

Yes indeed. I like Christophe's last idea though:

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 ;-).

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. Could you add a memset to String.create though? :-)

> That would confirm my intuition that the calls to f dominates the
> initialisation time.

In the case of Array.init, yes. From my array_init, inlining and 
type-specialisation decrease the time taken by ~43% and, hence, these would 
be the most productive optimisations.

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):

let array_init2 l f =
  if l = 0 then [||] else
  let x : int = f 0 in
  let res = Array.make l x in
  for i = 1 to pred l do
    Array.unsafe_set res i (f i)
  done;
  res

I'm not sure what the impact of the type-specialisation on inlining is though. 
I'd imagine that doing such partial specialisations in ocamlopt is 
arbitrarily dodgy because you don't get any feedback on the benfits of your 
results. Perhaps this is a challenge for Basile's JIT? :-)

Cheers,
Jon.

-------------------
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