Browse thread
[Benchmark] NBody
-
Christophe TROESTLER
- Will M. Farr
- Martin Jambon
-
skaller
-
Will M. Farr
- Ville-Pertti Keinonen
-
skaller
- Ville-Pertti Keinonen
- Marcin 'Qrczak' Kowalczyk
- Xavier Leroy
-
Will M. Farr
- Xavier Leroy
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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 <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/