From: Xavier Leroy <Xavier.Leroy@inria.fr>
Message-Id: <199610311526.QAA20258@pauillac.inria.fr>
Subject: Re: Q: float arrays
To: ohl@crunch.ikp.physik.th-darmstadt.de (Thorsten Ohl)
Date: Thu, 31 Oct 1996 16:26:38 +0100 (MET)
In-Reply-To: <9610301452.AA34276@crunch> from "Thorsten Ohl" at Oct 30, 96 03:52:28 pm
> I know that I'm asking too much, but wouldn't it be nice it the
> compiler did it for me? In the example at hand,
>
> let f2 = map (function (p,p') -> (p*.p'))
>
> the compiler could inline the multiplication automagically, iff it
> still had access to the definition of the map function.
That's right, and I still plan to put some automatic inlining in
Objective Caml at some point. However, known inlining strategies
are very conservative and err on the safe side in order to avoid code
size blowup. This means that if your "map" functional is sufficiently
big, it will not be inlined, even though this could resut in important
speedups.
I'm not trying to discourage anyone from writing polymorphic or
higher-order functions: if that makes the program clearer, do it and
the performances will be all right most of the time.
What I'm saying is that if the performances of your application depend
critically on a few functions (say, matrix operations, or a Fourier
transform), then one of the first things you should consider to
hand-optimize these functions is removing function parameters and
avoid polymorphic array accesses. This is much more important
performance-wise than, say, removing array bound checks or turning
recursive functions into loops.
- Xavier Leroy