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

121–130 of 553 posts

Re: Python 3.13 Gets a JIT

#121

Post by frankjr »

JodieBenitez wrote: post #61
jampekka wrote: post #49

Earlier quoted context omitted.

Python's SHA256 is written in C. And I'd quess Web Crypto API for JS is in the same ballbark. SHA256 in pure Python would be unusably slow. In Javascript it would be at least usably slow. Javascript is fast. Browsers are fast.

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/

Re: Python 3.13 Gets a JIT

#122

Post by lifthrasiir »

fer wrote: post #5

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/

PyPy was never able to get fast enough to replace CPython in spite of its lack of compatible C API. CPython is trying to move fast without breaking C API, and 2--9% improvement is in fact very encouraging for that and other reasons (see my other comment).

Re: Python 3.13 Gets a JIT

#123

Post by vanderZwan »

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…

> fucking cpython is allocating its integers on the heap and motherfucking reference-counting them

And here I thought that it was shocking to learn that v8 allocates doubles on the heap recently. (I mean, I'm not a compiler writer, I have no idea how hard it would be to avoid this, but it feels like mandatory boxed floats would hurt performance a lot)

Re: Python 3.13 Gets a JIT

#124

Post by lifthrasiir »

vanderZwan wrote: post #119
lifthrasiir wrote: post #113

Earlier quoted context omitted.

While bears a significant resemblance, Ertl and Gregg's approach is not automatic and every additional architecture requires a significant understanding of the target architecture---including an ability to ensure that fully relocable code can be generated and extracted. In comparison, the copy-and-patch approach can be thought as a simple dynamic linker, and objects generated by unmodified C compilers are far more pr…

Does Ertl and Gregg's approach have any "upsides" over copy-and-patch? Or is it a case of just missing those one or two insights (or technologies) that make the whole thing a lot simpler to implement?

I think so, but I can't say this any more confident until I get an actual copy of their paper (I used other review papers to get the main idea instead).

Re: Python 3.13 Gets a JIT

#126

Post by AndrewDucker »

bdd8f1df777b wrote: post #31
AndrewDucker wrote: post #23

Earlier quoted context omitted.

Always interested in replies to this kind of comment, which basically boil down to "Python is so slow that we have to write any important code in C. And this is somehow a good thing." I mean, it's great that you can write some of your code in C. But wouldn't it be great if you could just write your libraries in Python and have them still be really fast?

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?

Re: Python 3.13 Gets a JIT

#127

Post by AndrewDucker »

dagw wrote: post #39
AndrewDucker wrote: post #23

Earlier quoted context omitted.

Always interested in replies to this kind of comment, which basically boil down to "Python is so slow that we have to write any important code in C. And this is somehow a good thing." I mean, it's great that you can write some of your code in C. But wouldn't it be great if you could just write your libraries in Python and have them still be really fast?

But wouldn't it be great if you could just write your libraries in Python Everybody obviously wants that. The question is are you willing to lose what you have in order to hopefully, eventually, get there. If Python 3 development stopped and Python 4 came out tomorrow and was 5x faster than python 3 and a promise of being 50-100x faster in the future, but you have to rewrite all the libraries that use the C API, it w…

Why are you assuming that they'd have to rewrite all of their libraries? I don't see anything in the article that says that.

Re: Python 3.13 Gets a JIT

#128

Post by kragen »

vanderZwan wrote: post #123
kragen wrote: post #74

Earlier quoted context omitted.

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…

> fucking cpython is allocating its integers on the heap and motherfucking reference-counting them And here I thought that it was shocking to learn that v8 allocates doubles on the heap recently. (I mean, I'm not a compiler writer, I have no idea how hard it would be to avoid this, but it feels like mandatory boxed floats would hurt performance a lot)

nanboxing as used in spidermonkey (https://piotrduperas.com/posts/nan-boxing) is a possible alternative, but i think v8 works pretty hard to not use floats, and i don't think local-variable or temporary floats end up on the heap in v8 the way they do in cpython. i'm not that familiar with v8 tho (but i'm pretty sure it doesn't refcount things)

Re: Python 3.13 Gets a JIT

#129

Post by benrutter »

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.

This is so true!

A JIT compiler is a big deal for performance improvements, especially where it matters (in large repetitive loops).

Anyone cynical about the potential a python JIT offers should take a look at pypy which has a 5x speed up over regular python, mainly though JIT operations: https://www.pypy.org/

Re: Python 3.13 Gets a JIT

#130

Post by Someone »

blagie wrote: post #65
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…

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.

It should be fairly easy to add instruction fusing, where they recognize often-used instruction pairs, combine their C code, and then let the compiler optimize the combined code. Combining LOAD_CONST with the instruction following it if that instruction pops the const from the stack seems an easy win, for example.
Post reply on HN