[Mono-list] Re: dynamic optimizations in Mono JIT

[Paolo Molaro]

On 10/07/02 Dietmar Maurer wrote:
> On Sun, 2002-10-06 at 01:29, James Roberts wrote:
> > The ideal goal of the project would be to continuously 
> > improve application performance using a lightweight profiler 
> > in conjunction with on-line translator/optimizer.  However, 
> > since this is only a semester project, it would be sufficient 
> > to persue only a subset of those goals (e.g. a novel 
> > lightweight profiling technique, or simply an interesting 
> > feedback directed optimization for byte code translation).
> > 
> > I was wondering if you had any pending problems or project 
> > ideas in the Mono JIT which fell into this category and which 
> > would be feasible for a medium-sized class project.  
> > Likewise, I would greatly appreciate any pointers that you 
> > could give me regarding the high-level implementation of the 
> > Mono JIT.

As dietmar told you, we have a profiling interface, but that is
more directed at profiling applications that run in mono rather than
to instrument the code to recompile or optimize the generated code.

We're very interested in feedback directed optimizations (either
online, like, when running the program) or offline (run the programs a
few times collecting profile information and save them somewhere: the
next time the JIT runs it knows what methods it should fully optimize
from the start). This kind of profiling will be very valuable for us,
since we're writing a new JIT compiler that has more optimizations
than the current one and some of them may be too slow to enable by
default for all the methods. I guess you can still experiment with the
current JIT, by disabling gloabl register allocation by default
and using it only when recompiling methods that profiling shows to 
be hotspots.

Are you interested more in collecting profile data or in optimizing the
code?
In the first case you can either use simple counters or (more
interesting) use something like oprofile to collect info (oprofile uses
the hw cpu counters). I'm personally more interested in seeing profile
data collected for jitted programs with oprofile.

If you're interested in optimiing the code once hotspots have been
identified, you can:
1) tune the jit knobs to produce better code (global reg allocation)
2) write more optimizations for the jit.
3) enhance the binary code directly (interesting but less useful)

For item 2 I suggest waiting a few weeks for the new jit to come into
existance since that will be more easily improved (and I guess you
need time to design and collect profile data first anyway...).

lupus

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