[HN Gopher] Following Up on the Python JIT
___________________________________________________________________
Following Up on the Python JIT
Author : Bogdanp
Score : 82 points
Date : 2025-07-28 14:23 UTC (3 days ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| v3ss0n wrote:
| PyPy existed since a decade ago.
| orbisvicis wrote:
| If memory serves, PyPy supports a subset of Python and focused
| their optimizations on software transactional memory.
| iberator wrote:
| Back in 2022 it worked fine with literally all modules except
| some ssh, ssl and C based modules.
|
| With a little bit of tinkering (multiprocessing, choosing the
| right libraries written strictly in python, PyPy plus a lot
| of memory) I was able to optimize some workflows going from
| 24h to just 17 minutes :) Good times...
|
| It felt like magic.
| hnuser123456 wrote:
| Yep, I had a script that was doing some dict mapping and
| re-indexing, wrote the high level code to be as optimal as
| possible, and switching from cpython to pypy brought the
| run time from 5 minutes to 15 seconds.
| achierius wrote:
| The "C based modules" bit is the kicker. A significant
| chunk of Python users essentially use it as a friendly
| wrapper for more-powerful C/C++ libraries underneath the
| hood.
| Twirrim wrote:
| They've long since fixed the C based modules interaction,
| unfortunately a lot of common knowledge is from when it
| couldn't interact with everything.
|
| If you've written it off on that basis, I'd suggest it's
| worth giving it another shot at some stage. It might
| surprise you.
|
| Last I saw there was still a little bit more overhead
| around the C interface, so hot loops that just call out
| to a C module in the loop can be just a smidgen slower,
| but I haven't seen it be appreciably slower in a fair
| while.
| laurencerowe wrote:
| The FAQ states it is often much slower:
|
| > We have support for c-extension modules (modules
| written using the C-API), so they run without
| modifications. This has been a part of PyPy since the 1.4
| release, and support is almost complete. CPython
| extension modules in PyPy are often much slower than in
| CPython due to the need to emulate refcounting. It is
| often faster to take out your c-extension and replace it
| with a pure python or CFFI version that the JIT can
| optimize.
|
| https://doc.pypy.org/en/latest/faq.html#do-c-extension-
| modul...
|
| I have seen great success with cffi though.
| orbisvicis wrote:
| I see, and it's a pretty short list:
|
| https://doc.pypy.org/en/latest/cpython_differences.html#e
| xte...
|
| """ The extension modules (i.e. modules written in C, in
| the standard CPython) that are neither mentioned above
| nor in lib_pypy/ are not available in PyPy. """
|
| The lifecycle of generators makes pypy code very verbose
| without refcounting. I've already been bitten with
| generator lifecycles and shared resources. PEP533 to fix
| this was deferred. Probably for the best as it seems a
| bit heavy-handed.
| anthk wrote:
| If pypy worked with Retux the game would get a big boost.
| Altough the main issue is that it tried to redraw many
| object at one per frame.
| pansa2 wrote:
| PyPy deserves much more credit (and much wider use) than it
| gets. The underperformance of the Faster CPython project [0]
| shows how difficult it is to optimize a Python implementation,
| and highlights just how impressive PyPy really is.
|
| [0] The article says "Python has gotten nearly 50% faster in
| less than four years", but the original goal was a _5x_ speedup
| in the same timeframe [https://github.com/markshannon/faster-
| cpython/blob/master/pl...].
| Qem wrote:
| > The article says "Python has gotten nearly 50% faster in
| less than four years", but the original goal was a 5x speedup
| in the same timeframe
|
| IIRC they originally expected the JIT to be the single focus
| on CPython performance improvement. But then another front
| was opened to tackle the GIL in parallel[1]. Perhaps the
| overhead of two major "surgeries" in the CPython codebase at
| the same time contributed to slower progress than originally
| predicted.
|
| [1] https://peps.python.org/pep-0703/
| pjmlp wrote:
| The main culprit is not wanting to change the C ABI of the
| VM.
|
| Other equally dynamic languages have long shown the way.
| nromiun wrote:
| I really wish PSF would adopt PyPy as a separate project. It is
| so underrated. People still think it supports a subset of
| Python code and that it is slow with C ffi code
|
| But the latest PyPy supports all of Python 3.12 and it is just
| as fast with C ffi code as JIT Python code. It is literally
| magic and if it was more popular Python would not have a
| reputation for being slow.
| quibono wrote:
| Do you happen to know if Flask is supported by any chance?
| nromiun wrote:
| I just tested it and it works perfectly.
| tgbugs wrote:
| Yes, have been using Flask on PyPy3 for years. I get about
| a 4x speedup.
| Twirrim wrote:
| Yes. I've had a small webapp running under it quite happily
| (complete overkill, but it's a personal project and I was
| curious).
|
| Very basic hello world app hosted under gunicorn (just
| returning the string "hello world", so hopefully this is
| measuring the framework time). Siege set to do 10k
| requests, 25 concurrency, running that twice so that they
| each have a chance to "warm up", the second round (warmed
| up) results give me: pypy : 8127.44
| trans/sec cpython: 4512.64 trans/sec
|
| So it seems like there's definitely things that pypy's JIT
| can do to speed up the Flask underpinnings.
| ziml77 wrote:
| PyPy is amazing and it's actually a bit baffling that it's
| not the default that everyone is using in production. I've
| had Python jobs go from taking hours to run, down to minutes
| simply by switching to PyPy.
| almostgotcaught wrote:
| Why do people feel the need to comment this on every single JIT
| post? Like imagine commenting on every post about Pepsi "Coca-
| cola exists since 1886".
| pjmlp wrote:
| Because as proven multiple times, the problem isn't Python,
| rather CPython, and many folks keep mixing languages with
| implementations.
| didip wrote:
| I don't get why PyPy and CPython don't simply merge. It will be
| difficult, organization wise... but not impossible.
| pjmlp wrote:
| When people think of C library wrappers as Python is kind of
| an hard sell.
| pjmlp wrote:
| Unfortunately it keeps being the black swan in the Python
| community.
|
| Python is probably the only programming language community that
| has been so much against JITs, and where folks routinely call C
| libraries bindings, "Python".
| IshKebab wrote:
| It's not a black swan. The issue is that using Pypy means
| accepting some potential compatibility hassle, and in return
| you get a reasonable speedup in your Python code, from
| glacial to tolerable. But nobody who has accepted glacial
| speed really needs tolerable speed.
|
| It's like... imagine you ride a bike to most places. But now
| you want to visit Australia. "No problem, here take this
| racing bike! It's only a little less comfortable!".
|
| So really it's only of interest to people who have foolishly
| built their entire business on Python and don't have a
| choice. The only one I know of is Dropbox. I bet they use
| Pypy.
| iberator wrote:
| "For native profilers and debuggers, such as perf and GDB, there
| is a need to unwind the stack through JIT frames, and interact
| with JIT frames, but "the short answer is that it's really really
| complicated"
|
| I'm homeless and broken and I just spent like 2 weeks developing
| low level python bytecode tracer, and it SEEMS that this gonna
| ruin everything.
|
| This is hilarious - as its my first project in like 2 years
| achierius wrote:
| It's not impossible, JavaScript engines have the same challenge
| but are able to handle it. You do need to dump a lot of extra
| info but there's more or less a standard for this now -- look
| up JITDump
| klooney wrote:
| Is LWN the only professional media organization that covers this
| sort of thing? It seems like core, important news relevant to a
| large number of well heeled professionals, it's a little wild
| there's so little competition.
| Sesse__ wrote:
| Given that even LWN, with its consistently high-quality
| reporting, is struggling to make it, would there be room for a
| second one?
| klooney wrote:
| Probably not, which is sad.
| rs186 wrote:
| Most professional media organizations, including tech focused
| media, don't have a writer that remotely understands what's
| going on here.
|
| I know Ars Technica has a guy who can go deep into how a
| security attack works. That's the only one I am aware of from a
| well-known publication. Even so, if you look at the comment
| section, most people have no clue about technical details and
| are just talking about the story.
|
| Also bear in mind -- media in general is not a good industry to
| be in. Making money out of writing news articles is getting
| increasingly difficult. Most articles try to optimize for reach
| and clicks. Something like this one is not going to attract a
| lot of readers. I have no idea how LWN can be sustainable, but
| I can assure you that it's the exception, not the norm.
|
| Other than LWN, your best bet is reading this from someone's
| blog, who spends hours writing about it, trying to explain it
| in an understandable way and avoid mistakes, expecting almost
| nothing in return, just as a hobby.
|
| Your next best bet is reading someone's 12 disjointed tweets,
| possibly riddled with errors.
|
| That's just the world we are living in.
| sophacles wrote:
| > I have no idea how LWN can be sustainable, ...
|
| Speculation: LWN is sustainable because there are enough
| people out there who recognize the value of such a source of
| information and are willing to pay for a subscription.
|
| >... but I can assure you that it's the exception, not the
| norm.
|
| Anecdata: I credit a good portion of my success to knowledge
| and insight I've gained from lwn articles.
|
| If you're in a position to do so, I always recommend getting
| a paid membership, particularly if you've found their
| articles helpful to your tech journey.
|
| (i am not affiliated with LWN, just a happy subscriber)
| wmanley wrote:
| > I have no idea how LWN can be sustainable
|
| Speculation: it's because Linux (the kernel) is a large
| centralised project, so there's a critical mass of people
| willing to pay for Linux Weekly News.
|
| From there the proven quality allowed the publication to
| cover other OSS projects. I suspect that without Linux LWN
| would not be sustainable.
| satellite2 wrote:
| 100% or even 200% seems nice, but at least at the time when I
| compared with JavaScript it was 4200% faster than would have been
| needed. Let's not even mention go.
|
| At least for now it seems that Python can still only be used to
| call some Pascal or cuda bindings if one needs performance
| pjmlp wrote:
| Back in the 2000's I was on a startup whose main language was
| Tcl, and we would write C extensions for any performance
| critical command.
|
| The experience lead me to avoid any language without JIT or
| AOT, unless forced upon me.
|
| Hence why I have used Python since version 1.6 only for OS
| scripting tasks.
| mananaysiempre wrote:
| I don't know the timeline off-hand but I'm guessing this was
| before Tcl 8, at a time when everything in Tcl was a string
| not only logically, but also in the actual VM? There's a
| whole chasm of implementation tradeoffs between that to a
| straight-up JIT.
| lynx97 wrote:
| I wonder what is going on with the strange ""double quoting"".
| setupminimal wrote:
| Hi -- LWN editor here. We use <q> tags with some CSS to set off
| quotes from the main text. This _mostly_ works seamlessly, but
| a few browsers render "<q>something</q>" as ""something"". It's
| especially common if you copy/paste from the site.
|
| I've considered dropping the outer quotes and using CSS
| before/after text to add them back in to the rendered page, but
| we have a huge back-catalog of articles doing it this way, and
| it's usually not much of an issue.
| bratao wrote:
| I feel sad and disappointed in Microsoft for letting the entire
| Faster CPython team go. I was a big supporter, always leaving
| positive comments and sharing news about their work. I'd figure
| the team paid for itself in goodwill alone. What a letdown,
| Microsoft. You ought to do better.
| miohtama wrote:
| What's up with PyPy lately? Anyone using it in production?
| ziihrs wrote:
| Yep. It supports Python 3.11 now.
___________________________________________________________________
(page generated 2025-07-31 23:01 UTC)