This article is a fun read in light of Microsoft having laid off key parts of the very team this article is about. So much sweetness and light from 2.5 years ago. devblogs.microsoft.com/python/pytho... - ThreadSky

shriram.bsky.social • 41 days ago

This article is a fun read in light of Microsoft having laid off key parts of the very team this article is about. So much sweetness and light from 2.5 years ago.
https://devblogs.microsoft.com/python/python-311-faster-cpython-team/

Comments

dabeaz.com•41 days ago

This (https://discuss.python.org/t/community-stewardship-of-faster-cpython/92153) seems to suggest the achieved speedup to date hasn't even matched the first phase of this ambitious plan when it was proposed. So, while it gives me no pleasure to see it killed, maybe it's not unsurprising either.

shriram.bsky.social•41 days ago

I mean, this seems totally unsurprising, Python seems kinda' hopeless to speed up if you keep the language unchanged. I always assumed that the win here was not 50% for few programs but 1% for many programs. Did they overpromise?

ltratt.bsky.social•41 days ago

I think PyPy shows that the *language* can become fairly fast (not C speeds, of course!) but whether CPython the *implementation* can enable that is a more difficult question to answer (and one many have tried tackling).

shriram.bsky.social•41 days ago

Is PyPy 100% completely totally the same as Python? Every single program has exactly the same outcome?

ltratt.bsky.social•41 days ago

I wouldn't expect *exactly* the same outcome, but I would expect an outcome compatible with the language's semantics (and I believe PyPy delivers on this). Where life gets harder are things like C extensions, which are often (not intentionally) intertwined with CPython's implementation.

elfprince13.mumak.app•41 days ago

https://doc.pypy.org/en/latest/cpython_differences.html

dabeaz.com•41 days ago

My impression was that PyPy was nearly 100% compatible with "normal" Python programs, but you could get off in the weeds with certain techniques like stack frame introspection, C extension modules, etc.

samth.bsky.social•41 days ago

I believe the biggest incompatibility is that if you rely on when objects are collected it will be different. For C extensions it's mostly if they tried to use internals of the implementation (which happens of course).

sriku.org•40 days ago

The language is actually RPython is what I thought - https://rpython.readthedocs.io/en/latest/rpython.html . I suppose such a speed up effort is made somewhat redundant by Mojo. The lang must change tho. Python's __fn__ dynamics is its strength for flexibility and its Achilles heel for performance.

ltratt.bsky.social•40 days ago

RPython is really only meant for writing interpreters in ("RPython" is best thought of as both a restricted subset of Python / a language, and a meta-tracing system).

balakc.bsky.social•41 days ago

Do you have a pointer or two on the fundamental aspects of the language that make it impractical, if not impossible, to speed it up?

balakc.bsky.social•41 days ago

Never mind. Just started reading the original post and it already provides some hints.

dabeaz.com•41 days ago

Well, they were talking about something like a 50% speedup for *each* of 4 project phases! (https://github.com/markshannon/faster-cpython/blob/master/plan.md).

stefan-marr.de•41 days ago

The "language" isn't the problem though. The problem is the "language system" and the ecosystem around it.

Nobody wants a fast Python if they can't use their Python extensions.

Comments

Posting Rules

Reply