> 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. _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
