Python 3.13 Gets a JIT

Post by mkesper » Tue, Jan 09, 2024, 11:17 AM UTC

nyanpasu64 wrote: post #67

est31 wrote: post #15

Earlier quoted context omitted.

Python is already fast where it matters: often, it is just used to integrate existing C/C++ libraries like numpy or pytorch. It is more an integration language than one where you write your heavy algorithms in. For JS, during the time that it received its JITs, there was no cross platform native code equivalent like wasm yet. JS had to compete with plugins written in C/C++ however. There was also competition between…

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…

Post by bomewish » Tue, Jan 09, 2024, 11:21 AM UTC

Topfi wrote: post #64

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…

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.

Post by ptx » Tue, Jan 09, 2024, 11:22 AM UTC

kragen wrote: post #74

cube2222 wrote: post #43

Earlier quoted context omitted.

> ahead-of-time compilation is even better known for improving performance Not necessarily, not for dynamic languages. With very dynamic languages you can make only very limited assumptions about e.g. function argument types, which lead you to compiled functions that have to handle any possible case. A JIT compiler can notice that the given function is almost always (or always) used to operate on a pair of integers,…

yes, that is true. but aot compilers never make things slower than interpretation, and they can afford more expensive optimizations also, even mature jit compilers often only make limited improvements; jython has been stuck at near-parity with cpython's terrible performance for decades, for example, and while v8 was an enormous improvement over old spidermonkey and squirrelfish, after 15 years it's still stuck almost…

Post by boxed » Tue, Jan 09, 2024, 11:27 AM UTC

bomewish wrote: post #83

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.

Also recall that a 50% speed improvement in SQLite was caused by 50-100 different optimisations that each eeked out 0.5-1% speedups. On phone now don’t have the ref but it all adds up.

Post by checker659 » Tue, Jan 09, 2024, 11:31 AM UTC

vanderZwan wrote: post #82

I think it's really cool that Haoran Xu and Fredrik Kjolstad's copy-and-patch technique[0] is catching on, I remember discovering it through Xu's blog posts about his LuaJIT remake project[1][2], where he intends to apply these techniques to Lua (and I probably found those through a post here). I was just blown away by how they "recycled" all these battle-tested techniques and technologies, and used it to synthesize…