Live data from Hacker News

Python 3.13 Gets a JIT

tonybaloney.github.io

211–220 of 553 posts

Re: Python 3.13 Gets a JIT

#211
post #169

Earlier quoted context omitted.

AFAIK good JITs like V8 can do runtime introspection and recompile on the fly if types change. Maybe using the type hints will be helpful but I don't think they are necessary for significant improvement.

Are there any benchmarks that give an idea of how much this might improve Python's speed?

Well, GraalPython is a Python JIT compiler which can exploit dynamically determined types, and it advertises 4.3x faster, so it's possible to do drastically better than a few percent. I think that's state of the art but might be wrong.

That's for this benchmark:

https://pyperformance.readthedocs.io/

Note that this is with a relatively small investment as these things go, the GraalPython team is about ~3 people I guess, looking at the GH repo. It's an independent implementation so most of the work went into being compatible with Python including native extensions (the hard part).

But this speedup depends a lot on what you're doing. Some types of code can go much faster. Others will be slower even than CPython, for example if you want to sandbox the native code extensions.

Re: Python 3.13 Gets a JIT

#212
post #143
post #112

Earlier quoted context omitted.

And nobody writes short lived commands in those because of startup time.

Do a quick test with the latest JVM. Print Hello, world. That's it. Time it. Do the same with Python. The difference is minuscule. People don't build CLIs with them due to cultural reasons (fashion). Developers are creatures of fashion.

Printing hello world does not show the cost / benefit of a tracing jit that needs to be warmed up over thousands of iterations. And counter example: it takes maven 0.788s to realize I don't have a pom.xml in my PWD and fail a build. It takes meson 0.163s.

Re: Python 3.13 Gets a JIT

#213

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…

> This uses LLVM's JIT which is particularly slow and heavy (16MB added to the binary size) last time I tried to use it. Incorrect, LLVM is only used in the compile time. See my other comments for details.

I looked into PR and you're correct. That's at least better than expectations.

Re: Python 3.13 Gets a JIT

#214

Earlier quoted context omitted.

> "remember that CPython is already written in C" What is this supposed to say? Most scripting language interpreters are written in low level languages (or assembly), but that alone doesn't say anything about the performance of the language itself.

This means, that a lot of python libraries like polars or tensorflow are written not in python. So python programs, that already spend most of its cpu time running these libraries code, won't see much of an impact.

Isn't the point that if pure Python was faster they wouldn't need to be written in other [compiled] languages? Having dealt with Cython it's not bad, but if I could write more of my code in native Python my development experience would be a lot simpler.

Granted we're still very far from that and probably won't ever reach it, but there definitely seems to be a lot of progress.

Re: Python 3.13 Gets a JIT

#215
post #26
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.

anyone (company) stepping up and make the runtime as fast as modern JavaScript runtimes. There are a lot of faster python runtimes out there. Both Google and Instagram/Meta have done a lot of work on this, mostly to solve internal problems they've been having with python performance. Microsoft has also done work on parallel python. There's PyPy and Pythran and no doubt several others. However none of these attempts h…

Google/Instagram have done bits, but the company that's done the most serious work on Python performance is actually Oracle. GraalPython is a meaningfully faster JIT (430% faster vs 7% for this JITC!) and most importantly, it can utilize at least some CPython modules.

They test it against the top 500 modules on PyPI and it's currently compatible with about half:

https://www.graalvm.org/python/compatibility/

But investment continues. It has some other neat features too like sandboxing and the ability to make single-binary programs.

The GraalPython guys are working on the HPy effort as well, which is an attempt to give Python a properly specified and engine-neutral extension API.

Re: Python 3.13 Gets a JIT

#216
I still don't get why they didn't reduce API of the interpreter internals in Python 3 so that things like this would be more achievable.

If you're going to break backwards compatibility, it's not like Unicode was the only foundational problem Python 2 had.

Re: Python 3.13 Gets a JIT

#217

Earlier quoted context omitted.

> Julia tries to solve this (but fails due to implementation details) Care to list some of those details ? (I have zero knowledge in Julia)

This is quite a good intro: https://viralinstruction.com/posts/badjulia/

fyi: the author of that post is a current Julia user and intended the post as counterpoint to their normally enthusiastic endorsements. so while it is a good intro to some of the shortfalls of the language, I'm not sure the author would agree that Julia has "failed" due to these details

Re: Python 3.13 Gets a JIT

#218
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…

> That seems pretty expensive in terms of resource consumption. And complex as you would have to run some kind of watcher process which handles watching your files and restarting the application?

What? No, in reality it’s just running your app in debug mode (just a cli flag), and when you save the files the next refresh of the browser has the live version of the app. It’s neither expensive nor complex.

Re: Python 3.13 Gets a JIT

#219
post #205
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…

[deleted]

Re: Python 3.13 Gets a JIT

#220
post #169

Earlier quoted context omitted.

AFAIK good JITs like V8 can do runtime introspection and recompile on the fly if types change. Maybe using the type hints will be helpful but I don't think they are necessary for significant improvement.

Are there any benchmarks that give an idea of how much this might improve Python's speed?

Pypy is a different JIT that gives anything from slower/same to 100x speedup depending on the benchmark. They give a geometric mean of 4.8x speedup across their suite of benchmarks. https://speed.pypy.org/
Post reply on HN