Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

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: 2005-02-08 (12:04)
From: Marcin 'Qrczak' Kowalczyk <qrczak@k...>
Subject: Re: [Caml-list] [Benchmark] NBody
skaller <> 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