Live data from Hacker News

Python 3.13 Gets a JIT

tonybaloney.github.io

151–160 of 553 posts

Re: Python 3.13 Gets a JIT

#151
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.

Isn't it the case that Python allows for type specifier (type hints) since 3.5, albeit the CPython interpreter ignores them? The JIT might take advantage of them, which ought to improve performance significantly for some code. That what makes Python flexible is what makes it slow. Restricting the flexibility were possible offers opportunities to improve performance (and allows for tools and humans to spot errors more…

You can't really on type annotations to help interpret the code.

Re: Python 3.13 Gets a JIT

#152

Earlier quoted context omitted.

Yes, but not so good when the JIT-ed Python can no longer reference those fast C code others have written. Every Python JIT project so far has suffered from incompatibility with some C-base Python extension, and users just go back to the slow interpreter in those cases.

"not so good when the JIT-ed Python can no longer reference those fast C code others have written" I don't see an indication in the article that that's the case. Am I missing something?

this was a big obstacle for pypy specifically

https://www.pypy.org/posts/2011/05/numpy-follow-up-692862769...

https://doc.pypy.org/en/latest/faq.html#what-about-numpy-num...

i'm not sure what version they gave up at

Re: Python 3.13 Gets a JIT

#153

Earlier quoted context omitted.

Having recently implemented parallel image rendering in corrscope ( https://github.com/corrscope/corrscope/pull/450 ), I can say that friends don't let friends write performance-critical code in Python. Depending on prebuilt C++ libraries hampers flexibility (eg. you can't customize the memory management or rasterization pipeline of matplotlib). Python's GIL inhibits parallelism within a process, and the workaround o…

What would you use instead of Python?

Cython? :o

Re: Python 3.13 Gets a JIT

#154
post #112
post #104

Earlier quoted context omitted.

JS V8, Java (any JVM), .NET use JITs. If those aren't solid proving grounds for JITs, nothing is.

And nobody writes short lived commands in those because of startup time.

Rather those that don't know how to use the toolchains don't.

JIT caches, AOT have been an option for years.

And if you are really motivated, you can write stuff in C just like in Python.

Re: Python 3.13 Gets a JIT

#155
post #99

Earlier quoted context omitted.

I tried searching for that article because I vaguely recall it, but can't find it either. But yeah, a lot of small improvements add up. Reminds me of this talk: https://www.youtube.com/watch?v=NZ5Lwzrdoe8

Here is a source for the SQLite case: https://topic.alibabacloud.com/a/sqlite-387-a-large-number-o...

https://sqlite-users.sqlite.narkive.com/CVRvSKBs/50-faster-t...

Re: Python 3.13 Gets a JIT

#156
post #6

I always wondered how Python can be one of the world's most popular languages without anyone (company) stepping up and make the runtime as fast as modern JavaScript runtimes.

You might want to checkout Mojo, which is not a runtime but a different language, but also designed to be a superset of Python. Beware though that it's not yet open source, which is slated for this Q1

https://docs.modular.com/mojo/manual/

edit: The main point I forgot to mention - it aims to compete with "low-level" languages like C and Rust in performance

Re: Python 3.13 Gets a JIT

#157

Earlier quoted context omitted.

Have you tried to generate a SHA256 checksum for a file in the browser, no matter what crypto lib or api is available to you ? Have you tried to generate it using Python standard lib ? I did, and doing it in the browser was so bad that it was unusable. I suspect that it's not the crypto that's slow but the file reading. But anyway... > SHA256 in pure Python would be unusably slow None would do that because: > Python'…

Just for giggles I tried this and I'm getting ~200ms when reading and hashing 50MB file in the browser (Chromium based) vs ~120ms using Python 3.11.6. https://jsfiddle.net/yebdnz6x/

Not so bad compared to what I tried a few years ago. Might finally be usable for us...

Re: Python 3.13 Gets a JIT

#159
post #62
post #55

Earlier quoted context omitted.

Python with JIT is faster than Python without JIT. Having a Python with JIT, in many cases it will be fast enough for most cases. Data science running CUDA workloads isn't the only use case for Python.

I think Python without a JIT in many cases is already fast enough for most cases. I don't do data science.

I really wouldn't mind Python being faster than it is and I really didn't mind at all getting an practically free ~30% performance increase just by updating to 3.11. There's tons of applications which just passively benefit from these optimizations. Sure, you might argue "but you shouldn't have written that parser or that UI handling a couple thousand items in Python" but lots of people do and did just that.

Re: Python 3.13 Gets a JIT

#160
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…

You're right, and in this case "foundational work" even undersells how minimal this work really is compared to the results it already gets.

I recommend that people watch Brandt Bucher's "A JIT Compiler for CPython" from last year's CPython Core Developer Sprint[0]. It gives a good impression of the current implementation and its limitations, and some hints at what may or may not work out. It also indirectly gives a glimpse into the process of getting this into Python through the exchanges during the Q&A discussion.

One thing to especially highlight is that this copy-and-patch has a much, much lower implementation complexity for the maintainers, as a lot of the heavy lifting is offloaded to LLVM.

Case in point: as of the talk this was all just Brandt Bucher's work. The implementation at the time was ~700 lines of "complex" Python, ~100 lines of "complex" C, plus of course the LLVM dependency. This produces ~3000 lines of "simple" generated C, requires an additional ~300 lines of "simple" hand-written C to come together, and no further dependencies (so no LLVM necessary to run the JIT. Also "complex" and "simple" qualifiers are Bucher's terms, not mine).

Another thing to note is that these initial performance improvements are just from getting this first version of the copy-and-patch JIT to work at all, without really doing any further fine-tuning or optimization.

This may have changed a bit in the months since, but the situation is probably still comparable.

So if one person can get this up and running in a few klocs, most of which are generated, I think it's reasonable to have good hopes for its future.

[0] https://www.youtube.com/watch?v=HxSHIpEQRjs

Post reply on HN