Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 3.13 Gets a JIT

tonybaloney.github.io

Post reply on HN
Print view View original

251–260 of 553 posts

Re: Python 3.13 Gets a JIT

#251

Post by frakt0x90 »

crabbone wrote: post #243
cqqxo4zV46cp wrote: post #16

Unfortunate to see a couple of comments here drive-by pulling out the “x% faster” stat whilst minimising the context. This is a big deal and it’s effectively a given that this’ll pave the way for further enhancements.

I don't see this as an enhancement. Not pursuing JIT or efficient compilation in general was a deliberate decision way back when Python made some kind of sense. It was the simplicity of implementation valued over performance gains that motivated this decision. The mantra Python programmers liked to repeat was that "the performance is good enough, and if you want to go fast, write in C and make a native module". And i…

What are you talking about? From what I can read here there is no syntax change. Just a framework for faster execution. Plus, Python's usecase has HEAVILY evolved over the last few years since it's now the defacto language for machine learning. It's great that the core devs are keeping up with the time.

The language is definitely getting more complex syntactically, and I'm not a huge fan of some of those changes but it's no where near Java or C++ or anything else. You can still write simple Python with all of these changes.

Re: Python 3.13 Gets a JIT

#252

Post by simonw »

chaxor wrote: post #247
ageitgey wrote: post #3

For the lazy who just want to know if this makes Python faster yet, this is foundational work to enable later improvements: > The initial benchmarks show something of a 2-9% performance improvement. > I think that whilst the first version of this JIT isn’t going to seriously dent any benchmarks (yet), it opens the door to some huge optimizations and not just ones that benefit the toy benchmark programs in the standar…

Anyone know if there will be any better tools for cross-compiling python projects? The package management and build tools for python have been so atrociously bad (environments add far too much complexity to the ecosystem) that it turns many developers away from the language altogether. A system like Rust's package management, build tools, and cross compilation capability is an enormous draw, even without the memory s…

"It takes weeks to get simple packages working"

Can you expand on what you mean by that? I have trouble imagining a Python packaging problem that takes weeks to resolve - I'd expect them to either be resolvable in relatively short order or for them to prove effectively impossible such that people give up.

Re: Python 3.13 Gets a JIT

#253

Post by attractivechaos »

crabbone wrote: post #240
jjice wrote: post #200

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.

[flagged]

> There were no noticeable performance improvements in the course of the last two years.

In fairness, Python did get faster. Python 3.9 took 82 seconds for sudoku solving and 62 seconds for interval query. Python 3.11 took 53 and 43 seconds, respectively [1]. v3.12 may be better. That said, whether the speedup is noticeable can be subjective. 10x vs 15x slower than v8 may not make much difference mentally.

[1] https://github.com/attractivechaos/plb2

Re: Python 3.13 Gets a JIT

#254

Post by sgerenser »

Ringz wrote: post #201
Joker_vD wrote: post #183

Earlier quoted context omitted.

But type declarations in Python are not required to be correct, are they? You are allowed to write def twice(x: int) -> int: return x + x print(twice("nope")) and it should print "nopenope". Right?

Yep. Therefore it’s better to def twice(x: int) -> int: if not isinstance(x, int): raise TypeError("Expected x to be an int, got " + str(type(x))) return x + x

Surely this is the job for a linter or code generator (or perhaps even a hypothetical ‘checked’ mode in the interpreter itself)? Ain’t nobody got time to add manual type checks to every single function.

Re: Python 3.13 Gets a JIT

#255

Post by ncruces »

Someone wrote: post #238
ncruces wrote: post #227

Earlier quoted context omitted.

If it was that easy, you'd do that in the interpreter and proportionally reduce interpretation overhead.

In the interpreter, I don’t think it wouldn’t reduce overhead much, if at all. You’d still have to recognize the two byte codes, and your interpreter would spend additional time deciding, for most byte code pairs, that it doesn’t know how to combine them. With a compiler, that part is done once and, potentially, run zillions of times.

If fusing a certain pair would significantly improve performance of most code, you'd just add that fused instruction to your bytecode and let the C compiler optimize the combined code in the interpreter. I have to assume CPython as already done that for all the low hanging fruit.

In fact, for such a fused instruction to be optimized that way on a copy-and-patch JIT it'd need to exist as a new bytecode in interpreter. A JIT that fuses instructions is no longer a copy-and-patch JIT.

A copy-and-patch JIT reduces interpretation overhead by making sure the branches in the executed machine code are the branches in the code to be interpreted, not branches in the interpreter.

This is make a huge difference in more naive interpreters, not so much in an heavily optimized threaded-code interpreter.

The 10% is great, and nothing to sneeze at for a first commit. But I'd actually like some realistic analysis of next steps for improvement, because I'm skeptical instruction fusing and other things being hand waved are it. Certainly not on a copy-and-patch JIT.

For context: I spent significant effort trying to add such instruction fusing to a simple WASM AOT compiler and got nowhere (the equivalent of constant loading was precisely one of the pairs). Only moving to a much smarter JIT (capable of looking at whole basic blocks of instructions) started making a difference.

Re: Python 3.13 Gets a JIT

#256

Post by _bohm »

crabbone wrote: post #245
DeathArrow wrote: post #239

If JIT is a good thing for Python, why don't just compile to Java or .NET bytecode and use their already optimized infrastructure?

Given how many Microsoft employees today steer the Python decision making process, I'm sure in not so distant future, we might see a new CLR-based Python implementation. Maybe Microsoft don't know yet how to sell this thing, or maybe they are just boiling the frog. Time will tell. But I'm pretty sure your question will be repeated as soon as people will get used to the idea of Python on JIT.

Doesn't this already exist in IronPython?

Re: Python 3.13 Gets a JIT

#257

Post by vlovich123 »

attractivechaos wrote: post #242
ageitgey wrote: post #3

For the lazy who just want to know if this makes Python faster yet, this is foundational work to enable later improvements: > The initial benchmarks show something of a 2-9% performance improvement. > I think that whilst the first version of this JIT isn’t going to seriously dent any benchmarks (yet), it opens the door to some huge optimizations and not just ones that benefit the toy benchmark programs in the standar…

I wouldn't be so enthusiastic. Look at other languages that have JIT now: Ruby and PHP. After years of efforts, they are still an order of magnitude slower than V8 and even PyPy [1]. It seems to me that you need to design a JIT implementation from ground up to get good performance – V8, Dart and LuaJIT are like this; if you start with a pure interpreter, it may be difficult to speed it up later. [1] https://github.co…

PyPy is designed from the ground up and is still slower than V8 AFAIK. Don’t forget that v8 has enormous amounts of investment from professionally paid developers whereas PyPy is funded by government grants. Not sure about Ruby & PHP and it’s entirely possible that the other JIT implementations are choosing simplicity of maintenance over eking out every single bit of performance.

Python also has structural challenges like native extensions (don’t exist in JavaScript) where the API forces slow code or massive hacks like avoiding the C API at all costs (if I recall correctly I read that’s being worked on) and the GIL.

One advantage Python had is the ability to use multiple cores way before JS but the JS ecosystem remained single threaded longer & decided to use message passing instead to build WebWorkers which let the JIT remain fast.

Re: Python 3.13 Gets a JIT

#258

Post by Sesse__ »

londons_explore wrote: post #172
blagie wrote: post #65

Earlier quoted context omitted.

From the write-up, I honestly don't understand how this paves the way. I don't see an architectural path from a cut-and-paste JIT to something optimizing. That's the whole point of a cut-and-paste JIT.

> . I don't see an architectural path from a cut-and-paste JIT to something optimizing. One approach used in V8 is to have a dumb-but-very-fast JIT (ie. this), and keep counters of how often each block of code runs (perhaps actual counters, perhaps using CPU sampling features), and then any block of code running more than a few thousand times run through a far more complex yet slower optimizing jit. That has the bene…

Note that V8 didn't have a dumb-but-very-fast JIT (Sparkplug) until 2021; the interpreter (Ignition) did that block counting and sent it straight to the optimizing JIT (TurboFan).

V8 pre-2021 (i.e., only Ignition+TurboFan) was significantly faster than current CPython is, and the full current four-tier bundle (Ignition+Sparkplug+Maglev+TurboFan) only scores roughly twice as good on Speedometer as pure Ignition does. (Ignition+Sparkplug is about 40% faster than Ignition alone; compare that “dumbness” with CPython's 2–9%.) The relevant lesson should be that things like very carefully designed value representation and IR is a much more important piece of the puzzle than having as many tiers of compilation as possible.

Re: Python 3.13 Gets a JIT

#259

Post by dbrueck »

DeathArrow wrote: post #239

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.

Re: Python 3.13 Gets a JIT

#260

Post by eequah9L »

spacechild1 wrote: post #86
Topfi wrote: post #64

Earlier quoted context omitted.

Honestly, 2-9% already seems like a very signficant improvement, especially since as they mention "remember that CPython is already written in C". Whilst it's great to look at the potential for even greater gains by building upon this work, I feel we shouldn't undersell what's been accomplished.

> "remember that CPython is already written in C" What is this supposed to say? Most scripting language interpreters are written in low level languages (or assembly), but that alone doesn't say anything about the performance of the language itself.

I think they mean that a lot of runtime of any benchmark is going to be spent in the C bits of the standard library, and therefore not subject to the JIT. Only the glue code and the bookkeeping or whatnot that the benchmark introduces would be improved by the JIT. This reduces the impact that the JIT can make.
Post reply on HN