Re: [Caml-list] Re: multicore wish

[Jon Harrop <jon@ffconsultancy.com>]

On Thursday 24 December 2009 12:58:18 Goswin von Brederlow wrote:
> Jon Harrop <jon@ffconsultancy.com> writes:
> > On Tuesday 22 December 2009 18:02:32 Edgar Friendly wrote:
> >> On 12/22/2009 01:12 PM, Jon Harrop wrote:
> >> > On Tuesday 22 December 2009 13:09:27 Goswin von Brederlow wrote:
> >> >> The advantage with ocaml though is that you never have pointers into
> >> >> a structure. Makes thinks a lot simpler for the GC and avoids large
> >> >> overheads in memory.
> >> >
> >> > I don't understand what you mean by OCaml "never has pointers into a
> >> > structure". Half the problem with OCaml is that OCaml almost always
> >> > uses pointers and the programmer has no choice, e.g. for complex
> >> > numbers.
> >>
> >> I think he means that ocaml structs (records, tuples) will only ever
> >> have pointers pointing to their beginning - you can't have a pointer to
> >> somewhere in the middle of a structure.
>
> Exactly.
>
> > If so then I do not understand the relevance. You cannot have pointers
> > into a structure in F# or HLVM either...
>
> If you have an array a of (int * int) then in ocaml a is an array of
> pointers to tuples. a.(5) is a pointer to the 6th tuple.

Yes.

> You said that in F# the array will be really an array of tuples. Then
> a.(5) will be a pointer into the array at the position where the 6th
> tuple is.

No. The expression a.(5) loads all fields of the value type. For example, if 
it were an array of complex number then a.(5) would load the real and 
imaginary parts.

> That means as long as a.(5) is reachable the full array has to remain
> allocated or the GC has to recognise that only one (a few) items of an
> array are reachable and copy them before freeing the array. The GC
> also needs a way to find the begining of an allocated block from a
> pointer into the block. Which means extra overhead in both memory and
> time.
>
> Another think is that tuples are immutable but arrays are mutable. In
> ocaml you get this nice behaviour:
>
> # let a = Array.init 5 (fun x -> (x,x));;
> val a : (int * int) array = [|(0, 0); (1, 1); (2, 2); (3, 3); (4, 4)|]
> # let x = a.(1);;
> val x : int * int = (1, 1)
> # a.(1) <- (2,2);;
> - : unit = ()
> # x;;
> - : int * int = (1, 1)
>
> In F# you would get (2,2) for your fast sortable array. A different
> semantic.

No. Even if F# represented tuples as structs (which it does not, 
unfortunately) you would still get the same result as you do in OCaml.

HLVM already implements tuples as structs and your example works exactly as 
the OCaml does:

# let xs = create(6, (1, 1)) in let x = xs.(1) in xs.(1) <- (2, 2); x;;
- : `Struct[`Int; `Int] = (1, 1)

The only difference is that HLVM unboxes the pairs in the array so the heap 
contains only a single pointer and accessing a pair requires only one 
indirection.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e