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