[Mono-list] mono performance on highly recursive functions

Fergus Henderson fjh@cs.mu.OZ.AU
Tue, 18 Feb 2003 01:55:25 +1100


On 17-Feb-2003, Paolo Molaro <lupus@ximian.com> wrote:
> On 02/17/03 Fergus Henderson wrote:
> > There are lots of other optimizations which can be done at the IL->IL
> > level, many of which *do* require lots of processing time.  To avoid
> > duplicating these optimizations in multiple language front-ends, it makes
> > sense to have an IL->IL optimization tool.  Then you can do it once
> > in the IL->IL optimization tool, at zero run-time cost, rather than doing
> > it in the JIT at a small but non-zero cost in time and working set size
> > (due to the code for detecting when this optimization can be applied)
> > at run-time.
> 
> If you're willing to do the preprocessing, you can just use an ahead of
> time compiler: that will reduce the jit processing time much more than
> optimizing just the IL code.

Yes, but that sacrifices portability of the binary.

> There are also several reports at least by
> the MS people on how trying to outsmart the JIT by optimizing the IL
> code may result in the JIT missing some optimization opportunities.

I would be interested to see those.

I'm sure that there are some optimizations which are better done at
the JIT level.  But there are also some which are better done at
the IL->IL level.

> And I can understand that, a tool working on the IL code doesn't have
> all the info the JIT has.

That's true, but such a tool has time to compute more information than
a JIT can.  So neither has more information than the other; they have
different information.  It's useful to have optimization at both points.

> Anyway, even if you write an IL optimizer, the optimizations need to be
> implemented in the JIT, too: you can't always depend on having a
> preprocessor for IL code, think Reflection.Emit.

That is a good point; I wasn't considering that.
If you want to optimize the performance of programs which
uses Reflect.Emit to dynamically construct code on the fly,
then yes, it does make sense to put optimizations like
detecting tail recursion in the JIT.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.