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