Wilco (Wilco.Dijkstra.delete@this.ntlworld.com) on November 21, 2012 7:04 pm wrote:
> 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.


Sure, but that would (hopefully) be in a limited number of locations, and happen rather infrequently.


> 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...


Many real systems have various diagnostics that can be turned on dynamically - switching to a debug build is near impossible in many cases.