31–40 of 41 posts
Earlier quoted context omitted.
Static typing and JIT compiling aren't mutually exclusive. You can do all the static analysis, checking, whole-program optimization, etc. that's feasible at compile time, compile to bytecode, and then do JIT compilation at runtime. Edit: We appear to be in fierce agreement.
Exactly! I thought that was implicit in what I said. Maybe in the future static-typing's benefit would only be for program correctness.
Earlier quoted context omitted.
The runtime watches the code run, and if it notices that a specific type is in use in a certain code section, it rewrites the generated code to use that type when possible. For example, if you want to add all the integers from 1 to 2^31, the JIT will eventually realize that the accumulator can be a register (with a machine int in it) instead of a JavaScript big integer. (If that overflows, it will switch back.) Obvio…
One important issue is that compilation often needs to happen in bounded time. A JIT-compiler that does overly elaborate optimizations at runtime may lead to excessive pauses, and sometimes that's a dealbreaker. (Some of the same trade-offs appear with non-incremental garbage collection.)
There is always the risk of unbounded compilation time as you say... or at least compilation time that runs long enough that the compiled code isn't ready in time to be useful, but empirical evidence of tracing has shown it to be a net win (over interpretation) in every implementation I have seen, so this risk must be small or at least manageable.
Earlier quoted context omitted.
I think you're only considering static typing as an efficiency benefit. I'm equally as interested in its program-correctness benefits.
Static typing and JIT compiling aren't mutually exclusive. You can do all the static analysis, checking, whole-program optimization, etc. that's feasible at compile time, compile to bytecode, and then do JIT compilation at runtime. Edit: We appear to be in fierce agreement.
Static/Dynamic typing are no longer mutually exclusive either. We need to get past this idea already.
(I mean we as a field, not present company necessarily.)
Earlier quoted context omitted.
Static typing and JIT compiling aren't mutually exclusive. You can do all the static analysis, checking, whole-program optimization, etc. that's feasible at compile time, compile to bytecode, and then do JIT compilation at runtime. Edit: We appear to be in fierce agreement.
Static typing and JIT compiling aren't mutually exclusive, though Static/Dynamic typing are no longer mutually exclusive either. We need to get past this idea already. (I mean we as a field, not present company necessarily.)
Earlier quoted context omitted.
One important issue is that compilation often needs to happen in bounded time. A JIT-compiler that does overly elaborate optimizations at runtime may lead to excessive pauses, and sometimes that's a dealbreaker. (Some of the same trade-offs appear with non-incremental garbage collection.)
Many tracing JIT implementations do the compilation in a separate thread from the running VM, only providing the compiled code when it's ready. This reduces the overhead considerably, and should pretty much prevent any pauses in execution (assuming a CPU that can reasonably handle multiple threads). There is always the risk of unbounded compilation time as you say... or at least compilation time that runs long enough…
* I'm delighted that the LuaJIT port to amd64 is almost done, BTW. I've submitted two threads about it that haven't made it to the front page.
I'm confused. In the javascript space, it seems like V8 and squirrelfish (or is it Nitro? I prefer SF) have soundly trounced tracemonkey. Last time I checked, Squirrelfish isn't a tracing JIT centric implementation (nor is V8). I've yet to see a ttJIT javascript engine that hasn't been soundly trounced by the more conventional approaches. Perhaps it's different in the Lua world, but it seems to me like this post is c…
"Will a more static style JIT like Google's V8 be able to keep up?" V8 compiles everything to assembler and does not do JIT. V8 seems to beat TraceMonkey on both CPU and memory benchmarks ( http://shootout.alioth.debian.org/u64/benchmark.php?test=all... ), so I doubt their approach has "lost". They probably do this because most JavaScript programs are very small and it's relatively cheap to compile everything to asse…
2) Tracing JIT's might win for loop-centric languages. They miss some serious opportunities for parallelization in languages with rich collection-oriented operators (functional and array languages).
Can somebody please explain what a tracing JIT is?
Most systems start of by interpreting the some form of bytecode and observe which parts are executed most frequently and then compile these to machine code.
Now there are two main techniques for choosing what to compile: You can count how often each function/method is executed and then compile a method to machine code when the counter reaches a certain threshold. You can even compile several versions of the function, e.g., one for integers, one for floating point values.
A tracing JIT, on the other hand, does not compile single methods at once, but whole execution paths (traces) throughout the whole program (typically some kind of loop). A trace can span several methods and thus may allow better inter-procedural optimisations. For example if a certain if-branch is taken more frequently the trace will only include the common case and will fall back to the interpreter in the uncommon case.
Tracing JIT is probably more complicated than method-based JIT, because there are issues with code duplication (e.g., several traces may include the same code) and trace exits can be expensive, so you have to efficiently link traces together dynamically. However, trace-based JIT allows more agressive optimisations and, since traces tend to be longer than methods allow more optimisations in general.
For a good paper on how powerful a tracing-JIT can be, see http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.7...
With modern IDEs, tracing JIT, and type inference, I'm surprised that someone hasn't made the same lateral thinking sidestep that Hennessey & Patterson made for RISC. They offloaded much of the decoding work from the chip to the compiler, yielding faster chips in a smaller die size. Perhaps the Go language is the start of such a sidestep. We should be able to offload a lot of the work of type annotation to the IDE an…
You have just described Haskell. Annotate types if you want, let the compiler infer otherwise. Very dynamic feeling, but much safer. And you're right, it can make for some very fast code.