Faster CPython at PyCon, part two

Posted May 18, 2023 14:44 UTC (Thu) by kpfleming (subscriber, #23250)
In reply to: Faster CPython at PyCon, part two by Trou.fr
Parent article: Faster CPython at PyCon, part two

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

Posted May 21, 2023 21:06 UTC (Sun) by anton (subscriber, #25547) [Link] (2 responses)

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

Posted May 24, 2023 23:07 UTC (Wed) by 0xdky (guest, #141261) [Link] (1 responses)

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

Posted May 27, 2023 12:21 UTC (Sat) by Rudd-O (guest, #61155) [Link]

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.