Try using ChakraCore

[microsoft]

Try using ChakraCore

[rednaxelafx]

I got curious and took a look at the generated code the Pyjion currently produces for CoreCLR.
Here's a trivial example that I tried just to get a feel: http://zhuanlan.zhihu.com/hllvm/20591139 (the post is in Chinese, but the example code should say it all)

The boundary chosen between what's in MSIL and what's in "intrinsics" (or rather, runtime helper functions) seems to lean a lot towards leaving the heavyweight work in the intrinsics, and basically glue those intrinsics together with MSIL (so that CPython eval stack maps to MSIL eval stack, CPython "block stacks" are mostly computed at compile time, etc). It's certainly a good way to get started, to prove that there are performance gains, and also keep very compatible with CPython.

But if Pyjion chooses to try other backends (such as ChakraCore proposed here) with the same kind of translation strategy, that won't buy much in terms of performance, because there are too much information hidden behind these black boxes of "intrinsics".

Are there any other plans behind investigating using ChakraCore as opposed to CoreCLR / RyuJIT as Pyjion's backend? e.g. alternative translation strategies, or alternative tradeoff of the boundary between IR and intrinsics (runtime helper functions)?

[brettcannon]

Beyond this issue there are no other plans. 😄 We're really focused on proving performance first in some way in order to get the necessary APIs pushed upstream into Python. At this point, if we look at ChakraCore -- or any other JIT backend for that matter -- it will be to validate that the API for CPython we want to push upstream will make sense and not require changes in the future.

Specifically in terms of intrins.cpp, all of that code is for ease of development. If someone were to provide a pull request to replace one of those functions with a fully backwards-compatible IL emission then we would definitely take it.

[rednaxelafx]

Thanks for your reply, Brett! That's a totally understandable, pragmatic approach.

The issue of the currently proposed CPython API for JIT compilers is that, it seems to assume that JITs are going to use a Python function as a compilation unit, which doesn't take into the consideration of OSR from interpreter to compiled in the middle of a function, or Deoptimization (aka OSR exit) from compiled code back to the interpreter in the middle of a function.

Also, I can tell that the compilation policy is deliberately a simple one, where a function is JIT'd upon first invocation, synchronously. Apparently it's been considered to run a function a few times first before compiling (commented out for now). It'd also be nice to allow JITs to compile asynchronously / concurrent with the user code, so that startup performance wouldn't be affected by JIT'ing too much.
When I tried to play with Pyjion as it is right now, it feels sluggish when running the Python REPL as compared to normal CPython...

ChakraCore does both OSR (aka JsLoopBodyCodeGen in ChakraCore) and concurrent compilation. I believe both of those capabilities are good candidates to validate the effectiveness of the proposed C API from Pyjion.

[brettcannon]

So the sluggish feeling is because the JIT kicks in after about 4 executions which is way too aggressive. This is for testing purposes to exercise the JIT heavily. In production we would increase the number to 1,000 - 10,000 executions before triggering the JIT, but we have not tried to figure out the optimal number yet as we are still striving for CPython compatibility.

As for threaded JIT compilation, it's a possibility although we would have to think about race conditions, etc. which complicates matters. It also means we would require threaded support which Python does not require to begin with (although if you are using a JIT chances are you have threads 😄 ).

Lastly, compilation at the code object level (which maps to functions) is entirely on purpose and won't be changing. You have to realize that when you import a module in Python, you are compiling and then immediately executing the code, which means you can't do concurrent compilation as you have to maintain import order due to side-effects. It also means that when you do decide to trigger the JIT, you would have to track down every single code object associated with that module to make sure they are all updated and you don't leave unoptimized code objects lying around, and that is rather difficult to do without changing Python (this is why reloading a module in Python is highly discouraged beyond simply playing with things in the REPL).

I should clarify that when I say "validate", I simply mean "works", not "could it be improved to use some feature in another JIT". There will always be special features that a JIT could make use of if we simply added support. But to stay compatible and keep the scope consistent, we need to reign in what we expose. So if ChakraCore requires more than a function's scope for compilation then it simply won't work, but if it just could do more with it then we should be fine. As for the concurrent compilation, we can discuss that but that should be in a separate issue (feel free to open one if you want to discuss that topic further).

And it is critical to realize that this API cannot be complicated, else it will never be accepted upstream. The burden of maintaining this API must be minimized as much as possible while still allowing for useful work as the Python development team has no interest in maintaining a JIT, which means they also would not want to complicate CPython itself just to service JITs. Hence why the currently proposed API is as small and simple as it is: there is minimal cost to CPython to have it while still allowing us to actually add a JIT and stay compatible with CPython semantics.