From: Markus Mottl <mottl@miss.wu-wien.ac.at>
Message-Id: <199907181757.TAA31587@miss.wu-wien.ac.at>
Subject: optimization and purity
To: caml-list@inria.fr (OCAML)
Date: Sun, 18 Jul 1999 19:57:43 +0100 (MET DST)
Hello,
I would like to know whether anyone has already thought about means of
indicating or inferring purity of functions.
My specific problem:
I am just writing a library which features some functions that take
parameters which can only be generated by other functions of this module
(= the parameters have an abstract type).
E.g.:
let rec foo () = f (make_a a) (make_b b) ... in foo ()
The conversion functions like "make_a" or "make_b" may take a not
insignificant amount of time. I know that "f" will be heavily used within
recursive functions or loops and that the conversion functions are all
pure (=referentially transparent).
So the user can move these expressions outside of loops, because this
will not change semantics. He will even have to do this if he wants that
his code runs fast.
E.g.:
let made_a = make_a a
and made_b = make_b b in
let rec foo () = f made_a made_b ... in foo ()
But it can be tedious for the user to keep writing such code if
"f" is a very common function and if it takes numerous parameters.
Inexperienced users will probably not even know about such optimizations.
Thus, I have thought that it would be an interesting idea to tag all
kinds of external functions so as to indicate whether their evaluation
yields side effects or not.
E.g.:
external pure make_a : ...
This would permit some very interesting optimizations, because this
information allows the compiler to infer purity for all (better: nearly
all (*)) other functions. In the upper case the user would not need
to do optimization by hand - the compiler can see that e.g. "make_a"
is pure and may, if appropriate (the presence of conditionals can make
things difficult), move its evaluation outside of the loop.
(*) If a function makes use of only pure functions, it is always pure
itself. If a function contains calls to impure functions, it may be
that these functions will never be evaluated no matter what the input
to their "mother function" so this one is still pure as a whole. But
the latter case is not decidable...
Considering the paragraph on "Optimization" on the page
"http://caml.inria.fr/pub/old_caml_site/ocaml/numerical.html", I wonder whether there are
already intentions to implement some other "higher-level" optimizations
in the OCaml-compiler.
For example lambda-lifting would be nice - especially to me, because I
make heavy use of functions-within-functions, be it to restrict their
scope (yields less complex programs) or to bind names to values in the
environment of embracing functions (less parameters needed both for
function definition and for calls).
Small example for problem that could be eliminated with lambda-lifting:
let slow () =
let rec f () = () in
f ()
let rec f () = ()
let fast () = f ()
let _ = for i = 1 to 1000000 do slow () done
Best regards,
Markus Mottl
-- Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:23 MET