Interesting article on PyPy (P{ython's tracing JIT) by Laurence Tratt

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Interesting article on PyPy (P{ython's tracing JIT) by Laurence Tratt

Eliot Miranda-2
 
this is well written, relatively short, and extremely informative.

http://tratt.net/laurie/tech_articles/articles/fast_enough_vms_in_fast_enough_time

thanks to Bob  Westergaard for pointing it out to me. 
--
best,
Eliot

Reply | Threaded
Open this post in threaded view
|

Re: Interesting article on PyPy (P{ython's tracing JIT) by Laurence Tratt

Göran Krampe
 
On 02/09/2012 01:41 AM, Eliot Miranda wrote:
> this is well written, relatively short, and extremely informative.
>
> http://tratt.net/laurie/tech_articles/articles/fast_enough_vms_in_fast_enough_time
>
> thanks to Bob  Westergaard for pointing it out to me.

Yes, a very interesting and good article. And one aspect that he doesn't
really talk about is the fact that one gets *many* VMs on various
runtimes - not just one.

I recall when the PyPy project started and they presented it at OOPSLA
many years ago. At the time I think most people didn't think they would
"come through", but they sure did - eventually :)

regards, Göran
Reply | Threaded
Open this post in threaded view
|

Re: Interesting article on PyPy (P{ython's tracing JIT) by Laurence Tratt

David T. Lewis
In reply to this post by Eliot Miranda-2
 
On Wed, Feb 08, 2012 at 04:41:08PM -0800, Eliot Miranda wrote:
>  
> this is well written, relatively short, and extremely informative.
>
> http://tratt.net/laurie/tech_articles/articles/fast_enough_vms_in_fast_enough_time
>
> thanks to Bob  Westergaard for pointing it out to me.
> --
> best,
> Eliot

This is really interesting. Once again I am amazed at how much
I do not know about this stuff, which is both refreshing and a
intimidating at the same time. I'm also reminded of one of the
nicest aspects of the Squeak VM(s). It's so completely open and
accessible that anyone can pick it up and do useful work with it,
even me.

Thanks for the link!

Dave

Reply | Threaded
Open this post in threaded view
|

Re: Interesting article on PyPy (P{ython's tracing JIT) by Laurence Tratt

LawsonEnglish
In reply to this post by Eliot Miranda-2
 
On 2/8/12 5:41 PM, Eliot Miranda wrote:
 


this is well written, relatively short, and extremely informative.

http://tratt.net/laurie/tech_articles/articles/fast_enough_vms_in_fast_enough_time

thanks to Bob  Westergaard for pointing it out to me. 
--

Eliot, do you have plans to recreate the functionality of RPython to auto-generate JITs for other languages?

L.
Reply | Threaded
Open this post in threaded view
|

Re: Interesting article on PyPy (P{ython's tracing JIT) by Laurence Tratt

Eliot Miranda-2
 


On Thu, Feb 9, 2012 at 8:32 AM, Lawson English <[hidden email]> wrote:
 
On 2/8/12 5:41 PM, Eliot Miranda wrote:
 


this is well written, relatively short, and extremely informative.

http://tratt.net/laurie/tech_articles/articles/fast_enough_vms_in_fast_enough_time

thanks to Bob  Westergaard for pointing it out to me. 
--

Eliot, do you have plans to recreate the functionality of RPython to auto-generate JITs for other languages?

No.  This article confirmed David Simmons' conclusions as to the potential performance of tracing JITs, i.e. that they produce excellent performance for micro-benchmarks but overall perform poorly.  Here are some key quotes:

"It's clear that, in general, an RPython VM won't reach the performance of something like HotSpot, which has several advantages: the overall better performance of method-based JITs; the fact that it's hand-coded for one specific class of languages; and the sheer amount of effort put into it. But I'd certainly expect RPython VMs to get to comfortably within an order of magnitude performance levels as HotSpot. Time will tell, and as people write RPython VMs for languages like Java, we'll have better points of comparison."

"Tracing JITs are relatively new and have some limitations, at least based on what we currently know. Mozilla, for example, removed their tracing JIT a few months back, because while it's sometimes blazingly fast, it's sometimes rather slow. This is due to a tracing JIT optimising a single code-path at a time: if a guard fails, execution falls back to the (very slow) tracing interpreter for the remainder of that bytecode (which could be quite long), and then back to the language interpreter for subsequent bytecodes. Code which tends to take the same path time after time benefits hugely from tracing; code which tends to branch unpredictably can take considerable time to derive noticeable benefits from the JIT."

My own preferred direction remains to add adaptive optimization to Cog, after improving the object representation.

L.




--
best,
Eliot

Reply | Threaded
Open this post in threaded view
|

Re: Interesting article on PyPy (P{ython's tracing JIT) by Laurence Tratt

stephane ducasse-2

>> Eliot, do you have plans to recreate the functionality of RPython to auto-generate JITs for other languages?
>
> No.  This article confirmed David Simmons' conclusions as to the potential performance of tracing JITs, i.e. that they produce excellent performance for micro-benchmarks but overall perform poorly.  Here are some key quotes:
>
> "It's clear that, in general, an RPython VM won't reach the performance of something like HotSpot, which has several advantages: the overall better performance of method-based JITs; the fact that it's hand-coded for one specific class of languages; and the sheer amount of effort put into it. But I'd certainly expect RPython VMs to get to comfortably within an order of magnitude performance levels as HotSpot. Time will tell, and as people write RPython VMs for languages like Java, we'll have better points of comparison."
>
> "Tracing JITs are relatively new and have some limitations, at least based on what we currently know. Mozilla, for example, removed their tracing JIT a few months back, because while it's sometimes blazingly fast, it's sometimes rather slow. This is due to a tracing JIT optimising a single code-path at a time: if a guard fails, execution falls back to the (very slow) tracing interpreter for the remainder of that bytecode (which could be quite long), and then back to the language interpreter for subsequent bytecodes. Code which tends to take the same path time after time benefits hugely from tracing; code which tends to branch unpredictably can take considerable time to derive noticeable benefits from the JIT."
>
> My own preferred direction remains to add adaptive optimization to Cog, after improving the object representation.

Eliot may be I'm wrong but marcus told me recently that the tracing jit was removed from Javascript virtual machine (may be mozilla one)

Stef