LWN: Comments on "Faster CPython at PyCon, part two"

Faster CPython at PyCon, part two

Rudd-O — Sat, 27 May 2023 12:21:36 +0000

Google internally uses Python. But not as much. And almost all highly-performant code is C++ or Go or Java these days.

It's a matter of software quality constraints, mostly; back then, when we did not have mypy, it was comparatively harder to be certain that a Python program was gonna do what the programmer intended it to do after TAP was done TAPping, RAPID was done RAPIDing, and your PAR file was ready for your MPM (lengthy processes prior to deploy).

Modern Python with types (and a disciplined programmer who understands the type system) is almost as good as Go. Rust is still quite superior. Obviously these are only my opinions.

Faster CPython at PyCon, part two

0xdky — Wed, 24 May 2023 23:07:20 +0000

Could it be to reduce the cost of running a lot of analytics and ML jobs written in Python for these large cloud providers? If they can save on compute, they either get a bigger profit or can reduce the price and get more customers.

With the AI/ML wave, there could be uptick in Python based jobs running on public clouds.

Overall, I am very happy to see this improvements and technical content on LWN. Keep it coming!

Faster CPython at PyCon, part two

anton — Sun, 21 May 2023 21:06:04 +0000

Looking at the Unladen Swallow Retrospective, there was someone who was willing to do the work, and Google did initial funding, but eventually stopped funding it, because apparently nobody at Google uses Python for performance-critical work.

Still, as you write, there is interest in improving Python performance, maybe not because there is a product-related need for it, but because it is something that appeals to Python people; so the topic comes up again and again.

Faster CPython at PyCon, part two

kpfleming — Thu, 18 May 2023 14:44:52 +0000

AFAIK there wasn't any organization (company or other) willing to put resources into funding such a team until recently. There has been plenty of interest in improving performance and reducing memory consumption, but those aren't tasks that can reasonably be done by people who are not working on the interpreter full-time. The presenter of this talk (Mark Shannon) published a whitepaper and a roadmap, but it took a sponsor (in this case Microsoft, and then others) to take up the challenge and fund a group of developers to focus on it.

Faster CPython at PyCon, part two

Trou.fr — Mon, 15 May 2023 15:48:25 +0000

Thanks for the article. I'm very surprised the optimizations described in the two articles are only implemented now, as they seem basic (like caching lookups). Is there any simple/logic explanation as why nobody implemented them before?
I'd be genuinely interested in an article covering the Python ecosystem, a bit like the kernel contributors analysis. For a such a widely used language, the lack of a team focused on optimizing the runtime is extremely strange.

Faster CPython at PyCon, part two

ejr — Fri, 12 May 2023 23:00:06 +0000

ObLisp: Anyone consider the optimizations from CMUCL/SBCL's online compiler named... ... ... Python?