Pyjion requires: CPython 3.10 and .NET 6 .NET 6 Release: 19 hours ago ( https://github.com/dotnet/core/blob/main/release-notes/6.0/6... ) ... ok.
Pyjion 1.0 was released yesterday, so that checks out? :)
Pyjion – A Python JIT Compiler
101–110 of 126 posts
Re: Pyjion – A Python JIT Compiler
#102Earlier quoted context omitted.
I guess you are trying to imply that those documents cover a formal-enough description of what the execution and data model is. Well, even for the section "names" it just forgets to say if imported and non-imported names all share the same encoding and which should it be - just a nitpick, but with less than 5 seconds. Do you know that there are some behavioral limitations of dict that arise from a specific optimizati…
> Well, even for the section "names" it just forgets to say if imported and non-imported names all share the same encoding and which should it be - just a nitpick, but with less than 5 seconds https://www.python.org/dev/peps/pep-0263/ Names aren't unique. > Do you know that there are some behavioral limitations of dict that arise from a specific optimization in the implementation in C of dictionary iterators? I'm rat…
Sorry, but "names aren't unique" does not even begin to define uniqueness - "from ... import X" imports and X; great; should it replace an "X" in a different encoding in the local namespace, or not?
I can tell you it has to do with iterators, and maybe someone will comment on what that is.
Re: Pyjion – A Python JIT Compiler
#103Earlier quoted context omitted.
It certainly is good, but I've never found a great dev setup. It seems like you have to force a full recompile of all cython in the project any time you make a change. At least that was the stated process for the statsmodels library. And it was always a little unclear whether I was running the latest code or hadn't yet actually compiled it.
I've never used cython before. Is it 1-to-1 with standard Python? If so, can you do development using the regular Python binary, and leave the compilation step as a pre-commit operation?
It's not 1-1. Cython can compile regular Python, but you only really get significant speedups when you declare the types of things using cython-specific syntax.
Re: Pyjion – A Python JIT Compiler
#104Earlier quoted context omitted.
> Well, even for the section "names" it just forgets to say if imported and non-imported names all share the same encoding and which should it be - just a nitpick, but with less than 5 seconds https://www.python.org/dev/peps/pep-0263/ Names aren't unique. > Do you know that there are some behavioral limitations of dict that arise from a specific optimization in the implementation in C of dictionary iterators? I'm rat…
Sorry, but "names aren't unique" does not even begin to define uniqueness - "from ... import X" imports and X; great; should it replace an "X" in a different encoding in the local namespace, or not? I can tell you it has to do with iterators, and maybe someone will comment on what that is.
I mean... I had not even yet heard the talk that others have pointed you to (from Armin Ronacher); after having gone several times down the rabbit hole of looking at what the interpreter is doing in specific scenarios (and I like lots of things, at the language level, that python does, the terseness and expresiveness that it brings) I also think that python is a very complex language under a soft-looking skin.
Re: Pyjion – A Python JIT Compiler
#105Python is in a situation where it is enormously popular, due to a winning aesthetic in syntax/ergonomics that appeals to both newbies and experienced programmers. And due to this success, there is a lot of demand and interest in speeding the language up and getting rid of the GIL. But paradoxically, this veneer of simplicity hides an incredible amount of complexity. You have to read hundreds of lines of CPython to un…
Forget about language quirks, package management and version management in python is a nightmare. The ammount of time I wasted dealing with python environment related issues alone makes me avoid it if I can.
Re: Pyjion – A Python JIT Compiler
#106Earlier quoted context omitted.
> Can you point me at the proof for the soundness of the documented behavior java or javascript or C++ docs? https://link.springer.com/book/10.1007/3-540-48737-9 Java does have a formal semantics, with a whole chapter on its soundness. > in general, cpython is the spec Well there we go - turns out the written document doesn't cover everything after all. A second ago we were at 'Every guaranteed behavior of python is…
> Java does have a formal semantics, with a whole chapter on its soundness. No, there's a chapter on the soundness of its type system . The spec being sound and the type system being sound are very different things. If we consider typescript to be JS's type system, then JS's type system is unsound. If we consider cpython in isolation, under the definition you're using, cpython cannot be unsound, as it is untyped, QED…
You're arguing with the guy who did truffleruby. I'd say he knows a thing or 2 about the soundness of dynamic languages and adhering to a formal spec.
Re: Pyjion – A Python JIT Compiler
#107The overall speed-up factor (calculated from the numbers in the Benchmarks diagram, geomean of factors) is 1.6, which is much less than the factor 4 achieved with PyPy (or the even higher factor claimed by Graal Python). CLI is not very well suited for dynamic languages; as far as I remember the results presented here correspond with Iron Python, which is to be expected based on the proposed concept. EDIT: Yes, indee…
From the details on https://pypi.org/project/pyjion/ > Goal #1 is explicitly to add a C API to CPython to support JIT compilers. Given the plural compilers, hopefully this means it's going to support multiple JITs, which would be interesting. Choose the right JIT for your particular workload.
That particular statement was written several years ago. In practice, the API in question boils down to letting you plug in your own implementation of PyEval_EvalFrameEx. This has already been added in Python 3.9:
https://www.python.org/dev/peps/pep-0523/
As the PEP notes, this is useful for a lot more than just JIT. In particular, modern Python debuggers use it to dynamically patch bytecode to make breakpoints more efficient.
Re: Pyjion – A Python JIT Compiler
#108Does it have GIL? IronPython and Jython does not. https://wiki.python.org/moin/GlobalInterpreterLock How about Numpy performance?
It is not a complete rewrite. It basically just replaces the bytecode interpreter (which is a documented extensibility point) in regular CPython.
Re: Pyjion – A Python JIT Compiler
#109I don't really see the benefit over Nuitka, or even a JIT like Numba. Can someone help?
Neither of those is a drop-in replacement for CPython. It would be better to compare this project to, in addition to CPython: PyPy, GraalPython, Pyston, Cinder, Jython, and IronPython. As well as the now-inactive Psyco project, and possibly also Stackless Python.
It should be noted that Pyjion in particular is CPython. It's not even a fork - it's a native CPython module that provides a replacement for the stock bytecode interpreter (for which CPython has an API). Everything else is the same, so it's compatible with pretty much any random native module compiled for CPython.
Re: Pyjion – A Python JIT Compiler
#110Why is there so little mention of https://cython.org/ ? It's very fast, it compiles to C code, then compiles the C code with a normal compiler.
Cython is used very widely in the Python ecosystem. It's rarely mentioned precisly because it's so pervasive.
But it's also not the same thing - AOT doesn't always mesh well with how dynamic Python is, but JIT can take care of all the more advanced scenarios with runtime-loaded or runtime-generated types and code.