Another attempt to create JIT compiler for Python has failed

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Another attempt to create JIT compiler for Python has failed

Dibyendu Majumdar
Hi,

This may be of interest to anyone interested in creating JITs for
dynamic languages.

https://blog.pyston.org/

Javascript on the other hand has had a lot of success with multiple
successful JIT implementations.

Is Lua somewhere in between Python and Javascript? Unfortunately I do
not code in Javascript so I am not sure what makes it easier to
implement JIT for it compared to Lua.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Another attempt to create JIT compiler for Python has failed

Andrew Starks-2

On Mon, Feb 20, 2017 at 18:28 Dibyendu Majumdar <[hidden email]> wrote:
Hi,

This may be of interest to anyone interested in creating JITs for
dynamic languages.

https://blog.pyston.org/

Javascript on the other hand has had a lot of success with multiple
successful JIT implementations.

Is Lua somewhere in between Python and Javascript? Unfortunately I do
not code in Javascript so I am not sure what makes it easier to
implement JIT for it compared to Lua.

Regards
Dibyendu

This is a classic thread on that topic:


-Andrew
Reply | Threaded
Open this post in threaded view
|

Re: Another attempt to create JIT compiler for Python has failed

Hisham
In reply to this post by Dibyendu Majumdar
On 20 February 2017 at 21:28, Dibyendu Majumdar <[hidden email]> wrote:
> Hi,
>
> This may be of interest to anyone interested in creating JITs for
> dynamic languages.
>
> https://blog.pyston.org/
>
> Javascript on the other hand has had a lot of success with multiple
> successful JIT implementations.

I don't follow the Javascript space closely, and I always assumed that
V8 was the relevant player there when talking stand-alone JS
implementation, so this got me curious. Which are the other ones? The
ones sponsored by the other major browsers? (IIRC, Apple and Mozilla
have their own JS compilers). If that's the case, it seems to me
that's more of a matter of having major companies heavily invested in
the project (I believe Python performance is not critical for Dropbox
as Javascript performance is critical for a browser vendor — browsers
can't just switch to Go like Dropbox seems to be doing).

-- Hisham

Reply | Threaded
Open this post in threaded view
|

Re: Another attempt to create JIT compiler for Python has failed

Dibyendu Majumdar
On 21 February 2017 at 00:43, Hisham <[hidden email]> wrote:
> On 20 February 2017 at 21:28, Dibyendu Majumdar <[hidden email]> wrote:
>> Javascript on the other hand has had a lot of success with multiple
>> successful JIT implementations.
>
> I don't follow the Javascript space closely, and I always assumed that
> V8 was the relevant player there when talking stand-alone JS
> implementation, so this got me curious. Which are the other ones?

Mozilla SpiderMonkey
WebKit JavaScriptCore
Microsoft ChakraCore

And interesting none are tracing JITs as far as I know.

Regards

Reply | Threaded
Open this post in threaded view
|

Re: Another attempt to create JIT compiler for Python has failed

Dibyendu Majumdar
In reply to this post by Andrew Starks-2
On 21 February 2017 at 00:40, Andrew Starks <[hidden email]> wrote:

>
> This is a classic thread on that topic:
>
> http://lambda-the-ultimate.org/node/3851
>

Thanks for the link! What would be the conclusion to that debate 6 years later?

Regards

Reply | Threaded
Open this post in threaded view
|

Re: Another attempt to create JIT compiler for Python has failed

Eric Wing
In reply to this post by Dibyendu Majumdar
On 2/20/17, Dibyendu Majumdar <[hidden email]> wrote:

> On 21 February 2017 at 00:43, Hisham <[hidden email]> wrote:
>> On 20 February 2017 at 21:28, Dibyendu Majumdar <[hidden email]>
>> wrote:
>>> Javascript on the other hand has had a lot of success with multiple
>>> successful JIT implementations.
>>
>> I don't follow the Javascript space closely, and I always assumed that
>> V8 was the relevant player there when talking stand-alone JS
>> implementation, so this got me curious. Which are the other ones?
>
> Mozilla SpiderMonkey
> WebKit JavaScriptCore
> Microsoft ChakraCore
>
> And interesting none are tracing JITs as far as I know.
>
> Regards
>


I gave this talk at the Lua Workshop this past year "A Lua embedder
thrown into the JavaScript world".
https://www.youtube.com/watch?v=Xi_eMGO3g-o

My experience is that v8 is completely overrated. And I randomly
encounter other benchmarks, usually the automated nightly build type
where nobody is trying to prove anything, and those also show v8 is
overhyped. Typically, I see the others beat v8 in a lot of categories.
v8 might beat others in some very narrow types of benchmarks. But
overall, all the major ones seem roughly comparable in speed. And for
the real world (non-benchmarks), you see in my talk, v8 was awful for
me.

The NodeJS people are built on v8, so there is a lot of inertia.
However, building libraries on top of v8 is nuts, since C++ does not
guarantee ABI stability, and Google v8 themselves do not even
guarantee API stability, and have broken things.

JavaScriptCore on the other hand, provides a pure C API. And as far as
I know, they have not broken the API or ABI since its introduction way
back in Mac OS X many years ago. Apple understands and cares about
deeply, how to build libraries for other people to use. Appcelerator
switched away from dual v8/JSCore to all JavaScriptCore, and React
Native is also built on it now.

-Eric

Reply | Threaded
Open this post in threaded view
|

Re: Another attempt to create JIT compiler for Python has failed

Dibyendu Majumdar
Hi Eric,

On 21 February 2017 at 02:39, Eric Wing <[hidden email]> wrote:
> I gave this talk at the Lua Workshop this past year "A Lua embedder
> thrown into the JavaScript world".
> https://www.youtube.com/watch?v=Xi_eMGO3g-o

I had a quick look at your presentation. Thanks for sharing.

Last year I had the idea of extracting the new B3 JIT component
(https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/) from
JavaScriptCore so that I could use it to replace LLVM. LLVM is a very
big and very slow compiler (when compared to LuaJIT)  so I am always
looking for a leaner and faster solution. The B3 blog post above made
it look like this was a fairly standalone component.

While doing this I tried to build just the B3 component. It turned out
to be a lot of work as B3 seems to have lot of dependency on the
internals of JavaScriptCore. I just did not have the time to sort this
out so gave up on it. Additionally, I was disappointed that the B3 JIT
had dependency on ICU (via WTF) and Core Foundation Lite. This is sad
as these components have nothing to do with a JIT engine.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Another attempt to create JIT compiler for Python has failed

William Ahern
In reply to this post by Dibyendu Majumdar
On Tue, Feb 21, 2017 at 12:47:43AM +0000, Dibyendu Majumdar wrote:

> On 21 February 2017 at 00:43, Hisham <[hidden email]> wrote:
> > On 20 February 2017 at 21:28, Dibyendu Majumdar <[hidden email]> wrote:
> >> Javascript on the other hand has had a lot of success with multiple
> >> successful JIT implementations.
> >
> > I don't follow the Javascript space closely, and I always assumed that
> > V8 was the relevant player there when talking stand-alone JS
> > implementation, so this got me curious. Which are the other ones?
>
> Mozilla SpiderMonkey
> WebKit JavaScriptCore
> Microsoft ChakraCore
>
> And interesting none are tracing JITs as far as I know.

ChakraCore seems to implement both trace-based and method-based JIT
compilation:

  When ChakraCore notices that a function or loop-body is being invoked
  multiple times in the interpreter, it queues up the function in
  ChakraCore's background JIT compiler pipeline to generate optimized JIT'ed
  code for the function. Once the JIT'ed code is ready, ChakraCore replaces
  the function or loop entry points such that subsequent calls to the
  function or the loop start executing the faster JIT'ed code instead of
  continuing to execute the bytecode via the interpreter.

  Source: https://github.com/Microsoft/ChakraCore/wiki/Architecture-Overview

SpiderMonkey also seems to have a tracing JIT compiler:

  https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals/Tracing_JIT

It's more difficult to tell for JavaScriptCore. It seems much more like a
method-based JIT, but the documentation suggest some loop-based profiling

  FTL JIT kicks in for functions that are invoked thousands of times, or
  loop tens of thousands of times.

  https://trac.webkit.org/wiki/JavaScriptCore

Reading about microvm and their "Mu functions", maybe JavaScriptCore
compiles loops to tiny inline functions? They have a very complex
multi-stage compilation process that first compiles many methods to simple,
unoptimized machine code and then selects a subset of those for aggressive
compilation, so superfically seems like a possibility.


Reply | Threaded
Open this post in threaded view
|

Re: Another attempt to create JIT compiler for Python has failed

Ron Teitelbaum
Hi All,

http://www.mirandabanda.org/cogblog/about-cog/ might be of some interest!  

All the best,

Ron Teitelbaum


On Tue, Feb 21, 2017 at 9:54 PM William Ahern <[hidden email]> wrote:
On Tue, Feb 21, 2017 at 12:47:43AM +0000, Dibyendu Majumdar wrote:
> On 21 February 2017 at 00:43, Hisham <[hidden email]> wrote:
> > On 20 February 2017 at 21:28, Dibyendu Majumdar <[hidden email]> wrote:
> >> Javascript on the other hand has had a lot of success with multiple
> >> successful JIT implementations.
> >
> > I don't follow the Javascript space closely, and I always assumed that
> > V8 was the relevant player there when talking stand-alone JS
> > implementation, so this got me curious. Which are the other ones?
>
> Mozilla SpiderMonkey
> WebKit JavaScriptCore
> Microsoft ChakraCore
>
> And interesting none are tracing JITs as far as I know.

ChakraCore seems to implement both trace-based and method-based JIT
compilation:

  When ChakraCore notices that a function or loop-body is being invoked
  multiple times in the interpreter, it queues up the function in
  ChakraCore's background JIT compiler pipeline to generate optimized JIT'ed
  code for the function. Once the JIT'ed code is ready, ChakraCore replaces
  the function or loop entry points such that subsequent calls to the
  function or the loop start executing the faster JIT'ed code instead of
  continuing to execute the bytecode via the interpreter.

  Source: https://github.com/Microsoft/ChakraCore/wiki/Architecture-Overview

SpiderMonkey also seems to have a tracing JIT compiler:

  https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals/Tracing_JIT

It's more difficult to tell for JavaScriptCore. It seems much more like a
method-based JIT, but the documentation suggest some loop-based profiling

  FTL JIT kicks in for functions that are invoked thousands of times, or
  loop tens of thousands of times.

  https://trac.webkit.org/wiki/JavaScriptCore

Reading about microvm and their "Mu functions", maybe JavaScriptCore
compiles loops to tiny inline functions? They have a very complex
multi-stage compilation process that first compiles many methods to simple,
unoptimized machine code and then selects a subset of those for aggressive
compilation, so superfically seems like a possibility.


Reply | Threaded
Open this post in threaded view
|

Re: Another attempt to create JIT compiler for Python has failed

Javier Guerra Giraldez
In reply to this post by William Ahern
On 22 February 2017 at 02:54, William Ahern <[hidden email]> wrote:

> ChakraCore seems to implement both trace-based and method-based JIT
> compilation:
>
>   When ChakraCore notices that a function or loop-body is being invoked
>   multiple times in the interpreter, it queues up the function in
>   ChakraCore's background JIT compiler pipeline to generate optimized JIT'ed
>   code for the function. Once the JIT'ed code is ready, ChakraCore replaces
>   the function or loop entry points such that subsequent calls to the
>   function or the loop start executing the faster JIT'ed code instead of
>   continuing to execute the bytecode via the interpreter.
>
>   Source: https://github.com/Microsoft/ChakraCore/wiki/Architecture-Overview


I'm not sure that implies tracing, as it mentions "a background JIT
compiler" so it compiles separatedly from execution, while a trace
compiler gets as input the actual stream of instructions as executed
by the interpreter (so it gets data type information and code inlining
for free)

--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: Another attempt to create JIT compiler for Python has failed

Dibyendu Majumdar
In reply to this post by William Ahern
On 22 February 2017 at 02:54, William Ahern <[hidden email]> wrote:

> ChakraCore seems to implement both trace-based and method-based JIT
> compilation:
>
>   When ChakraCore notices that a function or loop-body is being invoked
>   multiple times in the interpreter, it queues up the function in
>   ChakraCore's background JIT compiler pipeline to generate optimized JIT'ed
>   code for the function. Once the JIT'ed code is ready, ChakraCore replaces
>   the function or loop entry points such that subsequent calls to the
>   function or the loop start executing the faster JIT'ed code instead of
>   continuing to execute the bytecode via the interpreter.
>
>   Source: https://github.com/Microsoft/ChakraCore/wiki/Architecture-Overview
>

I am not sure - I think this is saying that even while a method is
executing in the Interpeter, it can switch to a JIT compiled version
when a loop starts. I believe JVMs do this as well - i.e. switch from
interpreter to JIT code while executing a method.

> SpiderMonkey also seems to have a tracing JIT compiler:
>
>   https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals/Tracing_JIT
>

It is perhaps used in their baseline compiler? Their optimizing
compiler (https://wiki.mozilla.org/IonMonkey) is a whole method JIT as
per linked document. Certainly at one point they were using trace
compiler but I understood they moved away from that or I may be
mistaken here.

Regards
Dibyendu