Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[Caml-list] Floating point boxing again

1 view
Skip to first unread message

malc

unread,
Oct 24, 2002, 4:40:06 AM10/24/02
to caml...@inria.fr
let a n =
let x = ref 1.0 in
for i = 1 to n do
x := !x +. 1.0;
done;
!x

let b n =
let x = ref 1.0 in
for i = 1 to n do
x := !x +. 1.0;
done;
!x +. 0.0

The code produced for a and b respectively differ greatly, even the inner
loops. Can someone from Caml team clarify the issue?

P.S. Native code obviously.

--
mailto:ma...@pulsesoft.com

-------------------
To unsubscribe, mail caml-lis...@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Quetzalcoatl Bradley

unread,
Oct 25, 2002, 3:30:28 AM10/25/02
to caml...@inria.fr
Very interesting! On PowerPC, the code is also very different, and the
one with the spurious addition is MUCH faster. (factor of about 4.5
times faster)

version A keeps the reference up to date in memory for every iteration
of the loop. version B just accumulates the value in a register,
updating the reference at the end of the loop. Obviously, all the
updating of the reference is a lot of memory accessing.

I'm not familiar with the compiler internals but I can imagine how the
logic might look here. Perhaps the code generator looks at the
reference, and sees that in case A, the next use after the loop is
boxed (to return it), while in version B, it is unboxed (to add to it),
and concludes that in case A it will keep it boxed the whole time,
unboxed in case B.

Can anyone describe why the compiler will decide to keep the value
boxed/unboxed in the loop?

Thanks,

Quetzalcoatl Bradley
qbra...@blackfen.com

0 new messages