[Mono-list] mono performance on highly recursive functions

[Paolo Molaro]

On 02/18/03 Fergus Henderson wrote:
> > 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.

You still can use the IL binary (and even with an AOT compiler you need
the IL assembly anyway), so there is no loss of portability.

Note: doing the optimization in the JIT doesn't exclude someone from
optimizing the IL code too, it's just that we will focus on doing
the optimization at the jit level because we don't have the resources
for doing basically the same work multiple times. I guess third-party
compiler guys want their share of fun coding optimizations, so, more
power to them! :-)

> > 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.

The one I remember was about using a local to store the length of an
array and checking that in a for loop, instead of using the ldlen opcode
at each iteration.

> > 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.

Well, I guess once there is such a tool and we'll have the optimizations
implemented in the JIT we'll be able to compare what's most effective:-)

> > 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.

Well, we have already the ikvm JVM running with mono and that uses
Reflection.Emit (ok, I tried only two tests, fibonacci and ackermann,
but Zoltan has been doing a great job fixing issues with it). If you
factor out the startup cost (1.2 secs on my pentium III 1.13, but we
haven't tryed to optimized it yet), the speed is very competitive with
other free-software JVMs.
I also expect more 'scripting' languages will be implemented on the CLR
using Reflection.Emit in the next few months.

lupus

-- 
-----------------------------------------------------------------
lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better