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

111–120 of 553 posts

Re: Python 3.13 Gets a JIT

#111

Post by oblio »

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!

When did Microsoft start funding Python?

Also, such a shame that it takes sooo long for crucial open source to be funded properly. Kudos to Microsoft for doing it, shame on everyone else for not pitching in sooner.

FYI Python was launched 32 years ago, Python 2 was released 24 years ago and Python 3 was released 16 years ago.

Re: Python 3.13 Gets a JIT

#112

Post by guappa »

oblio wrote: post #104
fnord123 wrote: post #97

This could be headed for another dead end imo. Context: I use python for data processing and webdev. When doing data processing, Python is merely glue for libraries in compiled languages. When doing webdev, I mostly use python itself. First, any numbers regarding benchmarks need to be treated with contempt. JITs are unbenchmarkable. No matter what you do, someone says you do it wrong. Warmed up the JIT? You did it wr…

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.

Re: Python 3.13 Gets a JIT

#113

Post by lifthrasiir »

checker659 wrote: post #89
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…

M. Anton Ertl and David Gregg. 2004. Retargeting JIT Compilers by using C-Compiler Generated Executable Code. In Proceedings of the 13th International Conference on Parallel Architectures and Compilation Techniques (PACT '04). IEEE Computer Society, USA, 41–50. https://dl.acm.org/doi/10.5555/1025127.1025995

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 predictable and need much less architecture-specific information for linking.

Re: Python 3.13 Gets a JIT

#114

Post by lifthrasiir »

Iridescent_ wrote: post #60

Wasn't CPython supposed to remain very simple in its codebase, with the heavy optimization left for other implementations to tackle? I seem to remember hearing as much a few years back.

The copy-and-patch approach was explicitly chosen in order to minimize additional impacts on non-JIT-specific code base.

Re: Python 3.13 Gets a JIT

#115

Post by ngrilly »

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…

What would you use instead of Python?

Re: Python 3.13 Gets a JIT

#116

Post by masklinn »

adastra22 wrote: post #72
JodieBenitez wrote: post #61

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

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.

It absolutely is relevant to the "python is slow reee" nonsense tho, which is the subject. Python-the-language being slow is not relevant for a lot of the users, because even if they don't know they use Python mostly as a convenient interface to huge piles of native code which does the actual work.

And as noted upthread that's a significant part of the uptake of Python in scientific fields, and why pypy despite the heroic work that's gone into it is often a non-entity.

Re: Python 3.13 Gets a JIT

#117

Post by kragen »

ptx wrote: post #85
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…

There is already an AOT compiler for Python: Nuitka[0]. But I don't think it's much faster. And then there is mypyc[1] which uses mypy's static type annotations but is only slightly faster. And various other compilers like Numba and Cython that work with specialized dialects of Python to achieve better results, but then it's not quite Python anymore. [0] https://nuitka.net/ [1] https://github.com/python/mypy/tree/mas…

thanks, i'd forgotten about nuitka and didn't know about mypyc!

Re: Python 3.13 Gets a JIT

#118

Post by ubercore »

onetoo wrote: post #96
mg wrote: post #90

I love Python and use it for everything other than web development. One reason is performance. So if Python has a faster future ahead of it: Hurray! The other reason is that the Python ecosystem moved away from stateless requests like CGI or mod_php use and now is completely set on long running processes. Does this still mean you have to restart your local web application after any change you made to it? I heard that…

The restart isn't expensive in absolute terms, on a human level it's practically instant. You would only do this during development, hopefully your local machine isn't the production environment. It's also very easy, often just adding a CLI flag to your local run command. edit: Regarding performance, Python today can easily handle at least 1k requests per second. The vast vast vast majority of web applications today…

Been working with python for the web for over a decade. This is basically a solved issue, and the performance is a non-issue day to day.

Re: Python 3.13 Gets a JIT

#119

Post by vanderZwan »

lifthrasiir wrote: post #113
checker659 wrote: post #89

Earlier quoted context omitted.

M. Anton Ertl and David Gregg. 2004. Retargeting JIT Compilers by using C-Compiler Generated Executable Code. In Proceedings of the 13th International Conference on Parallel Architectures and Compilation Techniques (PACT '04). IEEE Computer Society, USA, 41–50. https://dl.acm.org/doi/10.5555/1025127.1025995

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?

Re: Python 3.13 Gets a JIT

#120

Post by fnord123 »

FartyMcFarter wrote: post #109
fnord123 wrote: post #97

This could be headed for another dead end imo. Context: I use python for data processing and webdev. When doing data processing, Python is merely glue for libraries in compiled languages. When doing webdev, I mostly use python itself. First, any numbers regarding benchmarks need to be treated with contempt. JITs are unbenchmarkable. No matter what you do, someone says you do it wrong. Warmed up the JIT? You did it wr…

> JITs are unbenchmarkable. No matter what you do, someone says you do it wrong. Why does that matter? Presumably if you care about Python performance, you have a real world scenario that you can benchmark. Just make a benchmark that is as representative as possible and check if the JIT helps. If it doesn't help, it surely can be disabled via an option.

> Why does it matter?

Because you need to have an idea of how many machines you need. And you need an idea of whether 'it will take as long as it takes' or if there's an issue in your code.

Sometimes Java decides to JIT using aes instructions. Sometimes it doesn't. Even if you run the same benchmark suite twice in a row it just does its own thing and gives wildly different results.

My learning was that one shouldn't depend on JIT performance and prefer using JNI libraries if you want consistency. Hence my comment being negative on JIT.

Post reply on HN