[Mono-list] Announce: A .NET assembly -> native code generation tool (ala ngen for MONO)

[Miguel de Icaza]

> This approach is what MS did.  This approach sucks.
> You just won't get good performance that way.
> 
> An ahead-of-time compiler can afford to spend a lot more time compiling,
> and as a result it can use much more sophisticated optimizations than
> a JIT compiler can.

When we say `Turn on all the optimizations' it means that you can turn
all of the expensive optimizations on.  There are many things that we
can not do at JIT time that we can do effectively if we have a lot of
time to spare.

This is for instance what the Intel ORP JIT engine does: it does a fast
JIT task that inserts profiling information into the code, and if those
trigger a threshold, then the routine is re-JITed with the slow
optimizing JIT engine.

> Note also that GCC's optimizer has already been ported to a lot more
> architectures than the mono JIT has been.  For architectures where
> the choice is to use an interpreter or an ahead-of-time compiler,
> the ahead-of-time compiler should give a very significant speedup.

Sure, and we are still evaluating the options, but we are going to
improve the JIT engine.

A large number of optimizations is performed on the intermediate
representation which means that every target will benefit from it, the
piece that is architecture dependent is the piece that actually matches
a IR tree to native instructions. 

For instance, constant folding, propagation and inlining in the Mono JIT
are all done on the intermediate representation.  CSE, GCSE, invariant
code motion and loop optimizations should all be performed on this IR,
and not in an architecture specific one.

Anyways, not advocating either case at this point, we will see how
things mature, and we are helping and keeping a close look at Zoltan's
approach.  Maybe it will become the default, but lets keep a scientific
mindset for now.

Miguel.