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

61–70 of 553 posts

Re: Python 3.13 Gets a JIT

#61

Post by JodieBenitez »

jampekka wrote: post #49
JodieBenitez wrote: post #35

Earlier quoted context omitted.

Because it's already fast enough for most of us ? Anecdote, but I've had my share of slow things in Javascript that are not slow in Python. Try to generate a SHA256 checksum for a big file in the browser... Good to see progress anyways.

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's SHA256 is written in C

Hence why comparing "pure python" to "pure javascript" is mostly irrelevant for most day to day tasks, like most benchmarks.

> Javascript is fast. Browsers are fast.

Well, no they were not for my use case. Browsers are really slow at generating file checksums.

Re: Python 3.13 Gets a JIT

#62

Post by eesmith »

pjmlp wrote: post #55
pdimitar wrote: post #54

Earlier quoted context omitted.

What do you mean by "it will shift the mentality"? There is no magical JIT that will ever make e.g. the data science Python & C++ amalgamations slower than a pure Python. Likely never happening, too. Also no mentality shift is expected on the "Python is too dynamic" -- which is a strange thing to say anyway -- because Python is not getting any more static due to these JIT news.

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.

Re: Python 3.13 Gets a JIT

#64

Post by Topfi »

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.

Re: Python 3.13 Gets a JIT

#65

Post by blagie »

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.

Re: Python 3.13 Gets a JIT

#66

Post by tgv »

cryptos wrote: 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.

Teaching. So many colleges/unis I know teach "Introduction to Programming" with Python these days, especially to non-CS students/pupils.

Re: Python 3.13 Gets a JIT

#67

Post by nyanpasu64 »

est31 wrote: post #15
cryptos wrote: 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.

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 of multiprocessing and shared memory is awkward, has inconsistencies between platforms, and loses performance (you can't get matplotlib to render directly to an inter-process shared memory buffer, and the alternative of copying data from matplotlib's framebuffer to shared memory wastes CPU time).

Additionally a lot of the libraries/ecosystem around shared memory (https://docs.python.org/3/library/multiprocessing.shared_mem...) seems poorly conceived. If you pre-open shared memory in a ProcessPoolExecutor's initializer functions, you can't close them when the worker process exits (which might be fine, nobody knows!), but if you instead open and close a shared memory segment on every executor job, it measurably reduces performance, presumably from memory mapping overhead or TLB/page table thrashing.

Re: Python 3.13 Gets a JIT

#68

Post by adastra22 »

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.

What is being accomplished then?

Re: Python 3.13 Gets a JIT

#69

Post by adonese »

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.

is it any different or comparable to numba or pyjion? Not following python closely in recent years but I recount those two projects with huge potential

Re: Python 3.13 Gets a JIT

#70

Post by dikei »

cturner wrote: post #33
irjustin wrote: post #13

Earlier quoted context omitted.

[flagged]

The article will be a confusing read to someone who does not know what a JIT is. Look at the paper after the heading "What is a JIT?" The first paragraph moves towards an answer - "compilation design that implies that compilation happens on demand when the code is run the first time" But then it backtracks on this and says that it could mean many things, and gets wishy-washy, and says that python is already a JIT. Th…

It's pretty clear to me.

>> JIT, or “Just in Time” is a compilation design that implies that compilation happens on demand when the code is run the first time.

>> What people tend to mean when they say a JIT compiler, is a compiler that emits machine code.

A JIT compiler is a compiler that emits machine code the first time that code is run, vs an AOT compiler which emits machine code when the code is built.

Post reply on HN