By: Linus Torvalds (torvalds.delete@this.linux-foundation.org), July 12, 2013 9:11 am
Room: Moderated Discussions
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.
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).
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.
So JIT's don't generally want to be anything like a "real compiler". But they do have advantages that can make vectorization easier due to the whole "we can try to be optimistic" approach, 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. But for those, you might be able to do a better job than a static compiler would.
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
>
> 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.
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).
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.
So JIT's don't generally want to be anything like a "real compiler". But they do have advantages that can make vectorization easier due to the whole "we can try to be optimistic" approach, 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. But for those, you might be able to do a better job than a static compiler would.
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
