By: ⚛ (0xe2.0x9a.0x9b.delete@this.gmail.com), July 12, 2013 10:48 am
Room: Moderated Discussions
Linus Torvalds (torvalds.delete@this.linux-foundation.org) on July 12, 2013 9:11 am wrote:
> bakaneko (nyan.delete@this.hyan.wan) on July 12, 2013 3:28 am wrote:
> >
> > Then just turn the JIT/virtual machine/whatever
> > into a full blown compiler backend already. GPU
> > drivers have one built in, no excuse for the
> > java sandbox not to do it.
>
> The latency concerns make that impossible in practice.
>
> Also, the one advantage of JIT's is that they can take dynamic behavior into account, so you actually want
> the ability to recompile code on the fly. That can help vectorization efforts: you can say "I'm going to assume
> there are no aliases, and trap if they ever happen" and recompile without vectorization on the trap.
The primary goal of JIT is to achieve better performance via code specialization. That's the only thing that can beat static compilation.
> But both of these issues very much mean that you want to only JIT fairly small sections of code
> at a time ((a) latency: because you cannot afford the non-linear effects of bug code and (b) recompiling:
> because you want to have many small "chunks" that you can re-JIT independently).
Constraining a JIT to only deal with fairly small sections of code has very little performance advantage over static compilation.
Larger chunks generally mean more runtime optimization opportunities.
> In fact, you generally don't want to JIT run-once (or run-few-times) instructions
> at all, because the JIT overhead (even if you don't do any optimizations at
> all you have to manage the memory for the translations) is too big.
If every basic block of Java bytecode is compiled into x86 machine code upon the 1st entry to the basic block, the overhead of the translation wouldn't be noticeable if it is combined with x86 code caching over application/library executions.
> So JIT's don't generally want to be anything like a "real compiler".
A performance-oriented JIT needs to be more advanced than a static compiler.
> But they do have advantages that
> can make vectorization easier due to the whole "we can try to be optimistic" approach,
The "we can try to be optimistic" approach to JIT (and anything else) is somewhat controversial because of the cost incurred by runtime detection. It is controversial also from the viewpoint that some optimistic methods (tracing) are mathematically weak.
> it's just that
> generally the JIT will have to be pretty quick and simple, so you'd only catch the fairly trivial and
> easy cases.
Catching trivial cases by a JIT isn't worth the effort. It has little advantage over static compilation because static compilation is capable of handling many of the trivial cases.
>But for those, you might be able to do a better job than a static compiler would.
A good JIT needs to generate code at least comparable in performance with code generated by a static compiler.
-Atom
> The thing to really look out for with JIT's are benchmarks, though. Particularly for small benchmarks with
> high repeat-counts, a JIT may do things that are completely unrealistic in the real world. You can get
> some totally unrealistic results that make a JIT look really stunningly good, even when it is complete crap.
> Even more so than with the kinds of tricks static compilers do (as discussed in this whole thread).
>
> Linus
> bakaneko (nyan.delete@this.hyan.wan) on July 12, 2013 3:28 am wrote:
> >
> > Then just turn the JIT/virtual machine/whatever
> > into a full blown compiler backend already. GPU
> > drivers have one built in, no excuse for the
> > java sandbox not to do it.
>
> The latency concerns make that impossible in practice.
>
> Also, the one advantage of JIT's is that they can take dynamic behavior into account, so you actually want
> the ability to recompile code on the fly. That can help vectorization efforts: you can say "I'm going to assume
> there are no aliases, and trap if they ever happen" and recompile without vectorization on the trap.
The primary goal of JIT is to achieve better performance via code specialization. That's the only thing that can beat static compilation.
> But both of these issues very much mean that you want to only JIT fairly small sections of code
> at a time ((a) latency: because you cannot afford the non-linear effects of bug code and (b) recompiling:
> because you want to have many small "chunks" that you can re-JIT independently).
Constraining a JIT to only deal with fairly small sections of code has very little performance advantage over static compilation.
Larger chunks generally mean more runtime optimization opportunities.
> In fact, you generally don't want to JIT run-once (or run-few-times) instructions
> at all, because the JIT overhead (even if you don't do any optimizations at
> all you have to manage the memory for the translations) is too big.
If every basic block of Java bytecode is compiled into x86 machine code upon the 1st entry to the basic block, the overhead of the translation wouldn't be noticeable if it is combined with x86 code caching over application/library executions.
> So JIT's don't generally want to be anything like a "real compiler".
A performance-oriented JIT needs to be more advanced than a static compiler.
> But they do have advantages that
> can make vectorization easier due to the whole "we can try to be optimistic" approach,
The "we can try to be optimistic" approach to JIT (and anything else) is somewhat controversial because of the cost incurred by runtime detection. It is controversial also from the viewpoint that some optimistic methods (tracing) are mathematically weak.
> it's just that
> generally the JIT will have to be pretty quick and simple, so you'd only catch the fairly trivial and
> easy cases.
Catching trivial cases by a JIT isn't worth the effort. It has little advantage over static compilation because static compilation is capable of handling many of the trivial cases.
>But for those, you might be able to do a better job than a static compiler would.
A good JIT needs to generate code at least comparable in performance with code generated by a static compiler.
-Atom
> The thing to really look out for with JIT's are benchmarks, though. Particularly for small benchmarks with
> high repeat-counts, a JIT may do things that are completely unrealistic in the real world. You can get
> some totally unrealistic results that make a JIT look really stunningly good, even when it is complete crap.
> Even more so than with the kinds of tricks static compilers do (as discussed in this whole thread).
>
> Linus
