Browse thread
[Caml-list] OCaml Speed for Block Convolutions
[
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: | -- (:) |
| From: | Hugo Herbelin <Hugo.Herbelin@i...> |
| Subject: | Re: [Caml-list] OCaml Speed for Block Convolutions |
William Chesters wrote:
> Hugo Herbelin writes:
> > Assume more generally that you can modify any local variable as in the
> > (standard) following example:
> >
> > let fact (mutable n) =
> > let mutable r = 1 in
> > while n > 0 do
> > r <- r * n;
> > n <- n - 1
> > done;
> > r
>
> This doesn't actually make life much easier for the compiler. On
> 32-bit machines [see other thread!], `r' must be a reference (in the
> C++ sense) to a heap object---64-bit float, plus header. In general
> it is not safe to overwrite the float value in the heap, if it's
> possible that other variables have been assigned to it. (unless floats
> are assigned by value not by reference, but in that case you get heap
> allocation at the time of assignment ...).
To be boxed or not is not a property of the language but of the
implementation. This means that the semantics for such a "x <- e"
for boxed values (may be floats) can only be the same as for unboxed
values, that is "assignment by value".
This means that "x <- e", compared to "x.contents <- e", wouldn't
avoid the heap allocation inherent to the boxing of floats, but would
just avoid the initial allocation of an extra ref block and the
subsequent indirections to set/get the value (assuming the cell is not
already cached in a register what perhaps the compiler is able to do).
Hugo
-------------------
To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr