Mark Roulo (nothanks.delete@this.xxx.com) on November 21, 2012 10:30 am wrote:
> Wilco (Wilco.Dijkstra.delete@this.ntlworld.com) on November 21, 2012 6:41 am wrote:
> > David Kanter (dkanter.delete@this.realworldtech.com) on November 20, 2012 11:07 pm wrote:
> > > Rohit (a.delete@this.b.c) on November 20, 2012 4:48 pm wrote:
> > > > David Kanter (dkanter.delete@this.realworldtech.com) on November 19, 2012 3:40 pm wrote:
> > > > > That's probably a common view. However, there are a number of optimizations that can net
> > > > > you huge performance gains and are only viable for JIT systems. I agree you want to do
> > > > > as much as possible in your compiler, but somethings require dynamic information.
> > > > >
> > > > > DK
> > > >
> > > > Which optimizations are these?
> > >
> > > Speculative multi-threading using a JIT.
> >
> > That's not at all JIT related. Has anyone ever shown a speedup using software-only speculation?
> > Automatic multihreading ARMs have been studied for many years. However even with special hardware
> > support to detect conflicts, fast rollbacks and spawning threads to different cores it never
> > seemed worth the relatively small speedups, especially not when you consider the extra power
> > for speculating. The big speedups were all in loops which can be dealt with normally.
> >
> > To repeat, I don't believe there are any optimizations which are much better done in a JIT than in
> > a static compiler. Even dynamic info like profiling works better when done the traditional way.
>
> A better example is the ability to inline through a virtual
> function based on the actual objects instantiated.
>
> As a real-world example, I once wrote a logging infrastructure in Java. The way it worked, if the logging
> was disabled at run-time, a no-op logging object was instantiated. Because the JIT could see that only
> one class (of an inheritance hierarchy) was instantiated, the calls to that object did not need to go through
> the V-Table. This allowed them to be inlined, which then allowed the JIT to further realize that nothing
> was happening, so the entire log call could be optimized away when logging was disabled.
>
> I don't think you can do this with a static compiler ... you can decide at compile-time to optimize
> away, but not at run-time (or if you can, I don't see how ...). Note also that this allowed for
> fine grained control ... logging could be enabled (at runtime, based on a config file) per-component.
> Again, the components for which logging was disabled had *NO* runtime overhead at all.

If you have the ability to dynamically switch between logging and no logging at runtime then you always have some overhead. Profile feedback indicates which virtual call is most common, and compilers add a check for that class and inline the call if it matches, and if not do the virtual call as usual. A JIT will have to do the same as at any point in time you could change the logging object.

If the language used supports it, you could specialize each function to a particular instance of the logging object. You track every write to the logging object and a JIT would flush its cache on a write. A static compiler would jump to the alternative set of functions. This has high overheads, causing huge code bloat and (for a JIT) repeated unnecessary retranslations, so except for special cases (eg. path specialization for GC) this approach isn't popular.

In reality for logging it's simpler just to have a debug and a release build...

Wilco