On Fri, 2007-06-01 at 09:53 +0100, Richard Jones wrote:
> On Fri, Jun 01, 2007 at 06:09:27PM +1000, skaller wrote:
> > But still, the algorithm is crude and I found it necessary
> > to allow:
> > 
> > 	fun f ...           // maybe inline
> > 	inline fun f 	    // try REALLY HARD to inline
> > 	noinline fun f      // never inline
> 
> Actually it's more useful to control the inlining of function when
> they are applied, rather than when they are defined. 

I plan to implement that too.

> In more general terms, it was found that turning off inlining in the
> Linux kernel reduced the code size by 25%:

> I bet that actually improved performance too, but unfortunately in the
> article above they don't measure that.

Yes, I believe that. Smaller is usually faster.

However in Felix it isn't quite so simple. The 'general' method
of calling a function involves:

(a) call 'malloc()' to allocate heap store
(b) link the store into the garbage collector
(c) construct the object by binding its environment in
(d) clone the object so recursion works
(e) apply the object by passing its apply() method the arguments
(f) later on, garbage collect the object

ALL these steps are eliminated by inlining, and that also
provides further optimisation opportunities. In particular,
it typically reduces all non-recursive function call chains
to a flat sequence of primitive monomorphic mutators.

The resulting code is VERY fast. The code with all closures
isn't quite so fast :)

The compiler does other optimisations, these are just
the extreme cases. 

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net