Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Benchmark] NBody
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Marcin 'Qrczak' Kowalczyk <qrczak@k...>
Subject: Re: [Caml-list] [Benchmark] NBody
skaller <skaller@users.sourceforge.net> writes:

> But the types in your record are mutable, and so it can't
> possibly work.

It does work: mutable floats are unboxed too (if there are no
non-float fields).

It would be different if OCaml used standalone references instead
of mutable fields. But mutable fields are not first-class entities,
so they can be unboxed. I think this is actually the reason of
their existence (instead of taking SML ref as a primitive, which
is implemented with a record with a mutable field in OCaml).

> Perhaps Ocaml is actually smart enough to optimise
>
> 	type r = { m: float; n: float };
> 	let x = Array.create 99 { m=0.0; n=0.0 } in
> 	x.[2] = { x.[2] with m = m + 1.0 };
>
> so x is represnted by an array of float,

It does not optimize it, even though it theoretically could.

It's not clear whether this would be an optimization. Having a large
field unboxed requires boxing a large object if it's taken out of the
array as a whole - this is an improvement only if memory savings (and
thus cache usage and GC time) outweigh slower element access.

And it is generally taken out as a whole, unless a particular
operation could be applied to the copy inside the array directly.
This requires analysis which I believe OCaml doesn't perform.
Floats are small enough to be kept in registers.

> and perhaps one could even optimise
>
> 	x.[2].m <- 22.0;
>
> even though it appears to be a type error (modifying
> an immutable field), it actually isn't, since you could
> always used functional update.

Since with the generic polymorphic representation of the array the
only way to implement it (in the absence of whole-program analysis)
is functional update, and it behaves exactly as functional update,
it's not surprising that OCaml doesn't allow this and requires to
use functional update explicitly.

> However it isn't clear Ocaml type system uses the most
> expressive typing of 'constness', i.e. that it propages
> 'mutable' ness correctly. 

There is nothing to propagate.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/