Can somebody please explain what a tracing JIT is?
Have Tracing JIT Compilers Won?
11–20 of 41 posts
Re: Have Tracing JIT Compilers Won?
#12Can somebody please explain what a tracing JIT is?
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.) Obviously addition is faster when it's one CPU instruction with no memory loads, so this is a big speed win.
JIT in general means you generate native code at runtime instead of at compile time.
Re: Have Tracing JIT Compilers Won?
#13With 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.
Re: Have Tracing JIT Compilers Won?
#14Can somebody please explain what a tracing JIT is?
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…
Often, there's more information at runtime than compile time. This may even be true at times for statically typed languages.
I think the static/dynamic type debate is just a vestige of the state of interpreter/compiler technology in the 80's. I wish everyone would get over it and introspect and debug their knee-jerk reactions so we can get on with the next stage of language implementation.
Re: Have Tracing JIT Compilers Won?
#15With 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.
I'd like this for a Smalltalk style OO environment. Strongtalk got partway there.
Re: Have Tracing JIT Compilers Won?
#16Earlier 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…
Often, there's more information at runtime than compile time. This may even be true at times for statically typed languages. I think the static/dynamic type debate is just a vestige of the state of interpreter/compiler technology in the 80's. I wish everyone would get over it and introspect and debug their knee-jerk reactions so we can get on with the next stage of language implementation.
Sure, because static typing doesn't mean you picked the best type, it just means that you picked a type.
If you statically type your function as Integer -> Integer because one invocation in a million uses an integer bigger than 2^63, you are taking a speed hit for the other 999,999 calls. But a tracing JIT can just use a machine integer those times, and only fall back to the arbitrary-size Integer when it needs to.
Re: Have Tracing JIT Compilers Won?
#17Earlier 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…
Often, there's more information at runtime than compile time. This may even be true at times for statically typed languages. I think the static/dynamic type debate is just a vestige of the state of interpreter/compiler technology in the 80's. I wish everyone would get over it and introspect and debug their knee-jerk reactions so we can get on with the next stage of language implementation.
Such as, for example, Java. Java probably had the first tracing JIT-based VM outside academia.
Re: Have Tracing JIT Compilers Won?
#18Earlier quoted context omitted.
Often, there's more information at runtime than compile time. This may even be true at times for statically typed languages. I think the static/dynamic type debate is just a vestige of the state of interpreter/compiler technology in the 80's. I wish everyone would get over it and introspect and debug their knee-jerk reactions so we can get on with the next stage of language implementation.
Such as, for example, Java. Java probably had the first tracing JIT-based VM outside academia.
That depends on whether you consider the Smalltalk and Self research at Sun and Xeroc PARC to be "academia". Much of the JVM optimization technology came directly from those.
http://selflanguage.org/documentation/published/index.html
The paper "An Efficient Implementation of Self" (http://selflanguage.org/documentation/published/implementati...) is a good overview.
Lua is another language with a great JIT compiler, LuaJIT. There are several papers about Lua (http://www.lua.org/doc/jucs05.pdf, http://www.lua.org/papers.html) and a bunch of good mailing list posts about LuaJIT (e.g. http://article.gmane.org/gmane.comp.lang.lua.general/58908).
Re: Have Tracing JIT Compilers Won?
#19Earlier quoted context omitted.
Such as, for example, Java. Java probably had the first tracing JIT-based VM outside academia.
That depends on whether you consider the Smalltalk and Self research at Sun and Xeroc PARC to be "academia". Much of the JVM optimization technology came directly from those. http://selflanguage.org/documentation/published/index.html The paper "An Efficient Implementation of Self" ( http://selflanguage.org/documentation/published/implementati... ) is a good overview. Lua is another language with a great JIT compiler,…
I was thinking Strongtalk + Tracing + Type inference.
Re: Have Tracing JIT Compilers Won?
#20Earlier quoted context omitted.
It helps that C is designed to have an almost one to one mapping between its native operators and machine operations and addressing modes. For example, the pre and post increment operators are expressions with side effects, can be confusing and can provoke undefined behaviour with ease. Having two variants also seems redundant. But the two variants may have different optimal translations to underlying CPU addressing…
not arguing with your general point, but the difference between pre and post increment is very useful when writing things like stacks and queues with pointers. these days maybe people use libraries or templates, but i suspect they were introduced for ease of programming, not ease of translation. [edit: really, it's two sides of the same coin. it's useful, so both c and cisc chips have it, so the two match up...]
> not arguing with your general point, but the difference between pre and post increment is very useful when writing things like stacks and queues with pointers.
Of course this only applies to ephemeral variants of those data structures.