Re: Numeric programming efficiency question

From: Xavier Leroy (Xavier.Leroy@inria.fr)
Date: Tue Mar 23 1999 - 18:12:27 MET


Date: Tue, 23 Mar 1999 18:12:27 +0100
From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: James Hague <jhague@dadgum.com>, caml-list@inria.fr
Subject: Re: Numeric programming efficiency question
In-Reply-To: <Pine.LNX.3.96.990322122948.12166A-100000@babba.advancenet.net>; from James Hague on Mon, Mar 22, 1999 at 12:33:11PM -0600

> type vector = {x: float; y: float; z: float};;
> let vadd a b = {x = a.x +. b.x; y = a.y +. b.y; z = a.z +. b.z};;
> let vec (a,b,c) = {x=a; y=b; z=c};;
> vadd vec(1.0,2.0,3.0) vec(10.0,20.0,30.0);;
>
> I'm curious if the "shape changing" vec routine is optimized away in such
> an expression. I would expect it to be, but that's just the wishful
> programmer in me.

The "vec" function is actually small enough to fall under the default
inlining threshold, and so it is inlined at the points of call.

In your example above (which should read
        vadd (vec(1.0,2.0,3.0)) vec((10.0,20.0,30.0));;
actually), the inlining doesn't work because it conflicts with
an earlier optimization on constant data structures (this will have to
be fixed some day). But in more complex examples such as

    let f x x' = vadd (vec(x +. x', 0.0, 0.0)) (vec (x -. x', 0.0, 0.0))

the calls to "vec" are really inlined away, and the intermediate results
x +. x' and x -. x' are not heap-allocated separately.

So, it's not too bad, although it might not generate optimal code all
the time due to the rather simple-minded inlining and unboxing
algorithms used in ocamlopt.

- Xavier Leroy



This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:21 MET