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

231–240 of 553 posts

Re: Python 3.13 Gets a JIT

#231

Post by onetoo »

mg wrote: post #205
onetoo wrote: post #96

Earlier quoted context omitted.

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…

The thing is, I don't run my applications locally with a "local run command". I prefer to have a local system set up just like the production server, but in a container. Maybe using WSGI with MaxConnectionsPerChild=1 could be a solution? But that would start a new (for example) Django instance for every request. Not sure how fast Django starts. Another option might be to send a HUP signal to Apache: apachectl -k rest…

I would still recommend running it properly locally, but whatever. Pseudo-devcontainer it is. I assume the code is properly volume mounted.

In production, you would want to run your app through gunicorn/uvicorn/whatever on an internal-only port, and reverse-proxy to it with a public-facing apache or similar.

Set up apache to reverse proxy like you would on prod, and run gunicorn/uvicorn l/whatever like you would on prod, except you also add the autoreload flag. E.g.

    uvicorn main:app --host 0.0.0.0 --port 12345 --reload
If production uses containers, you should keep the python image slim and simple, including only gunicorn/uvicorn and have the reverse proxy in another container. Etc.

Re: Python 3.13 Gets a JIT

#232

Post by yxhuvud »

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…

More glaring about the claimed performance gain is that they didn't mention what code they ran (as far as I could see). Was it a selected small piece of code or was it a big Django monolith? As I didn't see any mention of what code it was I'm going to assume the former, and that the latter will actually get worse performance. Because that is what typically happens when someone build a new JIT compiler. It takes a couple of iterations of optimizations for them to become useful on nontrivial code.

Re: Python 3.13 Gets a JIT

#233

Post by astrolx »

fnord123 wrote: post #101
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

> it will finally shift the mentality regarding "C/C++/Fortran libs are Python" But pjmlp, I use Python because it's a wrapper for C/C++/Fortran libs. - Chocolate Giddyup

I can dig it!

Re: Python 3.13 Gets a JIT

#234

Post by hyperman1 »

The article presents a copy and patch jit as something new, but I remember DOS's quickbasic doing the same thing. It generated very bad assembly code in memory by patching together template assembly blocks with filled in values, with a lot of INT instructions toward the quickbasic runtime, but it did compile, not interprete.

Re: Python 3.13 Gets a JIT

#235

Post by fulafel »

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.

Support for generating machine code at all seems like a necessary building block to me and probably is quite a bit of effort to work on top of a portable interpreter code base.

Re: Python 3.13 Gets a JIT

#236

Post by jhardy54 »

Ringz wrote: post #201
Joker_vD wrote: post #183

Earlier quoted context omitted.

But type declarations in Python are not required to be correct, are they? You are allowed to write def twice(x: int) -> int: return x + x print(twice("nope")) and it should print "nopenope". Right?

Yep. Therefore it’s better to def twice(x: int) -> int: if not isinstance(x, int): raise TypeError("Expected x to be an int, got " + str(type(x))) return x + x

This can have substantial performance implications, not to mention DX considerations.

Re: Python 3.13 Gets a JIT

#238

Post by Someone »

ncruces wrote: post #227
Someone wrote: post #130

Earlier quoted context omitted.

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.

If it was that easy, you'd do that in the interpreter and proportionally reduce interpretation overhead.

In the interpreter, I don’t think it wouldn’t reduce overhead much, if at all. You’d still have to recognize the two byte codes, and your interpreter would spend additional time deciding, for most byte code pairs, that it doesn’t know how to combine them.

With a compiler, that part is done once and, potentially, run zillions of times.

Re: Python 3.13 Gets a JIT

#240

Post by crabbone »

jjice wrote: post #200

The last two-ish years have been insane for Python performance. Something clicked with the core team and they obviously made this a serious goal of theirs and the last few years have been incredible to see.

[flagged]
Post reply on HN