281–290 of 553 posts
I love the description in the draft PR: 'Twas the night before Christmas, when all through the code Not a core dev was merging, not even Guido; The CI was spun on the PRs with care In hopes that green check-markings soon would be there; ... ... ... --enable-experimental-jit, then made it, And away the JIT flew as their "+1"s okay'ed it. But they heard it exclaim, as it traced out of sight, "Happy JIT-mas to all, and…
The last two-ish years have been insane for Python performance. Something clicked with the core team and they obviously made this a serious goal of theirs and the last few years have been incredible to see.
If JIT is a good thing for Python, why don't just compile to Java or .NET bytecode and use their already optimized infrastructure?
If JIT is a good thing for Python, why don't just compile to Java or .NET bytecode and use their already optimized infrastructure?
If you're interested in learning more about the challenges and tradeoffs, both Jython ( https://www.jython.org/ ) and IronPython ( https://ironpython.net/ ) have been around for a long time and there's a lot of reading material on that subject.
It beats Python on performance, supposedly, but compatibility has never been great.
If JIT is a good thing for Python, why don't just compile to Java or .NET bytecode and use their already optimized infrastructure?
The bit everyone wants: > The initial benchmarks show something of a 2-9% performance improvement. Which is underwhelming (as mentioned in the article), especially if we look at PyPy[0]. But it's a step forward nonetheless. [0] https://speed.pypy.org/
The last two-ish years have been insane for Python performance. Something clicked with the core team and they obviously made this a serious goal of theirs and the last few years have been incredible to see.
The article describes that the new JIT is a "copy-and-patch JIT" (I've previously heard this called a "splat JIT"). This is a relatively simple JIT architecture where you have essentially pre-compiled blobs of machine code for each interpreter instruction that you patch immediate arguments into by copying over them. I once wrote an article about very simple JITs, and the first example in my article uses this style: h…
At the end of the day, the number of optimizations that even a JIT can do on Python is limited because all variables are boxed (each time the variable is accessed the type of the variable needs to be checked because it could change) and then function dispatches must be chosen based on the type of the variable. Without some mechanism to strictly type variables, the number of optimizations will always be limited.
> The initial benchmarks show something of a 2-9% performance improvement. You might be disappointed by this number, especially since this blog post has been talking about assembly and machine code and nothing is faster than that right? Indeed, reading the blog post build much higher expectations