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

71–80 of 553 posts

Re: Python 3.13 Gets a JIT

#71

Post by vanderZwan »

epcoa wrote: post #20
wrd83 wrote: post #17

Honestly I don't understand the pessimistic view here. I think every release since Microsoft started funding python has increased high single digit best case performance. Rather than focussing on the raw number compare to python 3.5 or so. It's still getting significantly faster. If they keep doing this steady pace they are slowly saving the planet!

Sorry, but reality bites https://en.wikipedia.org/wiki/Amdahl%27s_law

It's not that simple.

Amdahl's Law is about expected speedup/decrease in latency. That actually isn't strongly correlated to "saving the planet" afaik (where I interpret that as reducing direct energy usage, as well as embodied energy usage by reducing the need to upgrade hardware).

If anything, increasing speed and/or decreasing latency of the whole system often involves adding some form of parallelism, which brings extra overhead and requires extra hardware. Note that prefetching/speculative execution kind of counts here as well, since that is essentially doing potentially wasted work in parallel. In the past boosting the clock rate the CPU was also a thing until thermodynamics said no.

OTOH, letting your CPU go to sleep faster should save energy, so repeated single-digit perf improvements via wasting less instructions does matter.

But then again, that could lead to Jevons Paradox (the situation where increasing the efficiency encourages more wasteful than the increase in efficiency saves - Wirth's Law but generalized and older, basically).

So I'd say there's too many interconnected dynamics at play to really simply state "optimization good" or "optimization useless". I'm erring on the side of "faster Python probably good".

[0] https://en.wikipedia.org/wiki/Jevons_paradox

Re: Python 3.13 Gets a JIT

#72

Post by adastra22 »

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'…

The Pytthon standard lib calls out to hand optimized assembly language versions of the crypto algos. It is of no relevance to a JIT-vs-interpreted debate.

Re: Python 3.13 Gets a JIT

#73

Post by vanderZwan »

dikei wrote: post #70
cturner wrote: post #33

Earlier quoted context omitted.

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.

Did you already know what a JIT was before reading the article though? Confirming what you already know is a different thing than grokking it the first time. Plus in my brief but intense experience as someone teaching programming to artistic types who are scared of maths, it's more useful to evaluate explanations by the possibility of being misunderstood and overwhelming, than the possibility of correctly interpreting it.

Re: Python 3.13 Gets a JIT

#74

Post by kragen »

cube2222 wrote: post #43
kragen wrote: post #36

Earlier quoted context omitted.

maybe, maybe not. time will tell. ahead-of-time compilation is even better known for improving performance and yet perl's compile-to-c backend turned out to fail to do that

> 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 an order of magnitude slower than c https://benchmarksgame-team.pages.debian.net/benchmarksgame/... which is (handwaving) like maybe a factor of 2 or 3 slower than self

typically when i can get something to work using numpy it's only about a factor of 5 slower than optimized c, purely interpretively, which is competitive with v8 in many cases. luajit, by contrast, is goddam alien technology from the future

with respect to your int×int example, if an int×int specialization is actually vastly superior, for example because the operation you're applying is something like + or *, an aot compiler can also insert the guard and inline the single-instruction implementation, and it can also do extensive inlining and even specialization (though that's rare in aots and common in jits). it can insert the guards because if your monomorphic sends of + are always sending + to a rational instance or something, the performance gain from eliminating megamorphic dispatch is comparatively slight, and the performance loss from inserting a static hardcoded guess of integer math before the megamorphic dispatch is also comparatively slight, though nonzero

this can fall down, of course, when your arithmetic operations are polymorphic over integer and floating-point, or over different types of integers; but it often works far better than it has any right to. in most code, most arithmetic and ordered comparison is integers, most array indexing is arrays, most conditionals are on booleans (and smalltalk actually hardcodes that in its bytecode compiler). this depends somewhat on your language design, of course; python using the same operator for indexing dicts, lists, and even strings hurts it here

meanwhile, back in the stop-hitting-yourself-why-are-you-hitting-yourself department, fucking cpython is allocating its integers on the heap and motherfucking reference-counting them

Re: Python 3.13 Gets a JIT

#75

Post by pdpi »

AndrewDucker wrote: post #23
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.

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?

languages don’t need to all be good at the same thing. Python currently excels as a glue language you use to write drivers for modules written in lower-level languages, which is a niche that (afaik) nobody else seems to fill right now.

While I’m all for making Python itself faster, it would be a shame to lose the glue language par excellence.

Re: Python 3.13 Gets a JIT

#76

Post by drbaba »

adonese wrote: post #69
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

I don’t know Pyjion, but I have used Numba for real work. It’s a great package and can lead to massive speed-ups.

However, last time I used it, it (1) didn’t work with many third-party libraries (e.g. SciPy was important for me), and (2) didn’t work with object-oriented code (all your @njit code had to be wrapped in functions without classes). Those two has limited for which projects I could adopt Numba in practice, despite loving it in the cases it worked.

I don’t know what limitations the built-in Python JIT has, but hopefully it might be a more general JIT that works for all Python code.

Re: Python 3.13 Gets a JIT

#77

Post by lumpa »

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.

There's a lot of effort going on to improve CPython performance, with optimization tiers, etc. It seems the JIT is how at least part of that effort will materialize: https://github.com/python/cpython/issues/113710

> We're getting a JIT. Now it's time to optimize the traces to pass them to the JIT.

Re: Python 3.13 Gets a JIT

#78

Post by superlopuh »

pdimitar wrote: post #54
pjmlp wrote: post #37

Earlier quoted context omitted.

It is a very big deal, as it will finally shift the mentality regarding: - "C/C++/Fortran libs are Python" - "Python is too dynamic", while disregarding Smalltalk, Common Lisp, Dylan, SELF, NewtonScript JIT capabilities, all dynamic languages where anything can change at any given moment

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.

I'm fairly certain that this is false, and am working on proving it. In the cases that Numba is optimised for it's already faster than plausible C++ implementations of the same kernels.

https://stackoverflow.com/questions/36526708/comparing-pytho...

Re: Python 3.13 Gets a JIT

#79

Post by kragen »

pjmlp wrote: post #58
kragen wrote: post #51

Earlier quoted context omitted.

this is great, thanks! but it sounds like it was an aot compiler, not a jit compiler; for example, it explains that a drawback of compiling functions to native code is that they use more memory, and that the compiler still produces bytecode for the functions it compiles natively, unless you suppress the bytecode compilation in project settings

Yeah, I guess if one wants to go more technical, I see it as the first step of a JIT that didn't had the opportunity to evolve due to market decisions.

i guess if they had, we would know whether a jit made newtonscript faster or slower, but they didn't, so we don't. what we do know is that an aot compiler sometimes made newtonscript faster (though maybe only if you added enough manifest static typing annotations to your source code)

that seems closer to the opposite of what you were saying in the point on which we were in disagreement?

Re: Python 3.13 Gets a JIT

#80

Post by gray_-_wolf »

adastra22 wrote: post #68
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.

What is being accomplished then?

2-9%
Post reply on HN