13 ms·

This may be a somewhat uninformed opinion, but I think CPython is just straight up not particularly good software. There are a million and one optimizations tha

This may be a somewhat uninformed opinion, but I think CPython is just straight up not particularly good software. There are a million and one optimizations that other major scripting runtimes (V8, LuaJIT, PyPy, Ruby YJit etc.) have had for years that CPython is lacking. This is by design though. CPython has never been focused on performance, that's why it's not even JIT. It optimizes for simplicity and easy interoperability with C. The problem is that because Python is such a ubiquitous language, CPython gets more attention than it deserves. People see it as an archetypical implementation of a scripting language. We get blogposts like this examining its inner workings, discussions about how its performance could be improved, comparisons of its speed vs. compiled languages, and tutorials on how to optimize code to run faster in it. I feel like all of this effort would be better spent on discussions about runtimes that actually try to be fast.

deleted 3y ago
[deleted]
lifthrasiir 3y ago
Python rather happened to have a language design and C API design that doesn't allow a simple performant implementation. Even PyPy was not that fast compared to other JIT implementations, while its C API support was always subpar. It is easy to say that Python should trade them off for performance, but they are one of the key reasons for Python's success after all.
- whizzter 3y ago
  The semantic issues of making a performant Python language implementation are more or less exactly the same as for JS and Lua, optimizing Ruby seems to possibly have even more "magic" that needs patching but we've seen the Shopify team get cracking on that (it includes MaximeCB that did HiggsJS). PyPy is in many aspects to be rated as a research project that tried a novel approach to reduce the workload compared to the manhours poured into V8,etc. LuaJIT managed with less with a focused language and a really capable lead. (Also I wouldn't be surprised if the PyPy team has also had to make compromises to get some kind of compatibility)
  - lifthrasiir 3y ago
    Unfortunately Python's innard is much more complicated than most expectations. You have named JS and Lua, but those languages never have "magic" methods---JS instead has prototypes and more recently proxies, while Lua has metatables. Ordinary objects aren't magic in this sense, and conversely magical objects are generally deliberate choices in those languages. But Python's magic `__dunder__` methods are everywhere including ordinary objects (and customized objects that look like ordinary objects, e.g. `list` subclasses). That alone complicates a lot of things.
    - masklinn 3y ago
      It’s not entirely true that JS does not have magic methods. `valueOf` and `toString` can show up surprisingly deep into the resolution of operations, and recent JS has “well known symbols” to implement or override behaviour. However it is true that this is much, much less extensive than it is in Python. As of 3.12, section 3.3 (“special method names”) of the data model documentation lists 107 entries (although some of them only apply to class protocols, and a handful are duplicates for async versions / context of sone operations).
      - lifthrasiir 3y ago
        `valueOf` and `toString` are indeed fairly complex (and it's fun to consider when both are implemented ;-), but less of concern for tracing JIT engines because you can have efficient type-specialized implementations for most cases. Type specialization in Python is not that huge win...
    - Sesse__ 3y ago
      Also, you have craziness like quite regular iteration being implemented using exceptions, which are not exactly trivial to optimize.
      - lifthrasiir 3y ago
        If you want to be return absolutely any value from an iterator, an exception is indeed a reasonable choice though. Python generators came in much later, unlike JS for example.
sp332 3y ago
The last couple of CPython versions have had dramatic speed improvements, so that demonstrates your point but also gives some hope that things are changing on that front.
- coldtea 3y ago
  Dramatic? Barely. Even less than half of the non-dramatic speed improvements they promised. The promise was like "5 times faster in the next 4 releases", and the improvements in 2 releases thus far was like 20% at best (so not even 2x faster). Compared to JS pre-and-after modern engines it's a tiny improvement.
mseepgood 3y ago
If this is by design and it optimizes for simplicity and easy interoperability with C, why would you assess its quality as 'good software' based on criteria that are non-goals?
- Asraelite 3y ago
  In my eyes, "good software" does not necessarily just mean something that accomplishes its goals. You can set a goal of being bad, and that's kind of what CPython is doing. Of course, "good" and "bad" are relative. If you don't care about performance then there's nothing wrong with CPython.
  - acqq 3y ago
    I agree with that estimate, I think it was really the idea of Python to be less than "good" by design. I mean one doesn't need more than: >>> exit Use exit() or Ctrl-D (i.e. EOF) to exit to see. They have that special handling, but they still don't want to let you out, because... IMO, they just want to be annoying. When a solution could be something like: Note: exit() is needed in scripts. In this prompt Ctrl-D (i.e. EOF) can also be used. Exiting.
    - heyodai 3y ago
      Yeah, that message is a pet peeve of mine. Like, you know what I'm trying to do.
      - Smaug123 3y ago
        It sort of doesn't! It's just doing exactly the same thing it would do with any other identifier: it's printing its `repr`. Try `repr(exit)`!
        a1369209993 3y ago
        More to the point, try `[len,exit,repr]`. Consider what would happen if `exit.__repr__()` did terminate the program.
zitterbewegung 3y ago
I don't disagree with you but, now you can retrofit a JIT into python. https://blog.pyston.org/2022/09/29/announcing-3-7-3-10-support-and-a-new-direction/ https://blog.pyston.org/2022/09/29/announcing-3-7-3-10-suppo...
- acqq 3y ago
  "We think of the breakdown roughly as follows: of our roughly 30% original speedup, 10% is going into Pyston-lite, 10% was done independently by the CPython team between 3.8 and main, and the remaining 10% we are hoping to contribute back upstream." To compare with Javascript: if I remember, as it appeared, V8 JIT was orders of magnitude faster, compared to the interpreted code.
  - zitterbewegung 3y ago
    There was also a bunch of effort being put into efficiency of JavaScript. But now the tables have been changed and Microsoft is putting a large amount of effort into Python .
heavyset_go 3y ago
Recent CPython development has been towards optimizations and addressing use cases that benefit from optimizations, some coming from the faster CPython initiative. You might just get your JIT[1]. At the same time, I also agree with your sentiment. [1] https://github.com/faster-cpython/ideas/wiki/Workflow-for-3.12-cycle#trace-optimized-interpreter https://github.com/faster-cpython/ideas/wiki/Workflow-for-3....
nostrademons 3y ago
It's great software for the use case that Python is intended for. Python is supposed to be glue code. You embed a scripting runtime in your application, do all the heavy lifting in C, but configure your building blocks in Python so that you can easily reconfigure them as needs change. NumPy, SciPy, TensorFlow, PyTorch, JAX, Pandas, Pillow, lxml, cjson, PyCapnP, Tornado, fast-avro, etc. all get it right. They are wrappers around C (or in some cases: Fortran/assembly/CUDA) code, where the overflow of Python method dispatch is dwarfed by the hundreds of thousands of iterations of an inner loop that's in optimized, vectorized assembly. Django, Protobufs, and Avro get it wrong (often for portability or developer velocity sake), where they wrote the whole library in Python at the expense of performance. I was briefly tempted to write an API-compatible reimplementation of Django with the core in C++ when I left Google, but by then Django (and server-side web programming) was already falling out of favor, and if you're just shipping JSON to a SPA you can use cjson with any number of fast wsgi or asgi gateways.
- bb88 3y ago
  I've been playing around with HTMX with Django, and it seems simple enough for server side rendering. It works well with the Django templating system. I feel like as an industry we should step back and take a serious look at front end frameworks from first principles. One aspect that's clear to me, is that we should make modifications to HTML to support HTMX like transactions.
- oivey 3y ago
  Arguably no one’s goal is to glue pieces of C together. That’s too abstract. Their goal is to do something like write a performant web server, maybe easily and quickly. Python’s approach is one way to do that, but there are other ways that might be better. Having to write code in two languages to solve a problem, one of which that is difficult to write and has lots of footguns, has some clear downsides.
  - nerdponx 3y ago
    Ritchie and Thompson might disagree with you.
  - 3y ago
matheusmoreira 3y ago
Just yesterday I compared the small language I created to Python. Was surprised my tree walking interpreter somehow beat Python's bytecode virtual machine at recursive Fibonacci. It was just a simple hyperfine benchmark so I might be confounding code execution performance with the initialization time. Still caught me totally off guard and gave me a huge confidence and motivation boost. I was thinking something like "OK let's see just how bad this thing is" but it actually beat Python at something.
genman 3y ago
I really enjoined working in Lua.
ouraf 3y ago
Is there any comprehensive comparison and benchmark of intepreted languages or languages with a REPL and analysis of how each interpreter handles common operations?

deleted 3y ago

[deleted]

lifthrasiir 3y ago

Python rather happened to have a language design and C API design that doesn't allow a simple performant implementation. Even PyPy was not that fast compared to other JIT implementations, while its C API support was always subpar. It is easy to say that Python should trade them off for performance, but they are one of the key reasons for Python's success after all.

whizzter 3y ago
The semantic issues of making a performant Python language implementation are more or less exactly the same as for JS and Lua, optimizing Ruby seems to possibly have even more "magic" that needs patching but we've seen the Shopify team get cracking on that (it includes MaximeCB that did HiggsJS). PyPy is in many aspects to be rated as a research project that tried a novel approach to reduce the workload compared to the manhours poured into V8,etc. LuaJIT managed with less with a focused language and a really capable lead. (Also I wouldn't be surprised if the PyPy team has also had to make compromises to get some kind of compatibility)
- lifthrasiir 3y ago
  Unfortunately Python's innard is much more complicated than most expectations. You have named JS and Lua, but those languages never have "magic" methods---JS instead has prototypes and more recently proxies, while Lua has metatables. Ordinary objects aren't magic in this sense, and conversely magical objects are generally deliberate choices in those languages. But Python's magic `__dunder__` methods are everywhere including ordinary objects (and customized objects that look like ordinary objects, e.g. `list` subclasses). That alone complicates a lot of things.
  - masklinn 3y ago
    It’s not entirely true that JS does not have magic methods. `valueOf` and `toString` can show up surprisingly deep into the resolution of operations, and recent JS has “well known symbols” to implement or override behaviour. However it is true that this is much, much less extensive than it is in Python. As of 3.12, section 3.3 (“special method names”) of the data model documentation lists 107 entries (although some of them only apply to class protocols, and a handful are duplicates for async versions / context of sone operations).
    - lifthrasiir 3y ago
      `valueOf` and `toString` are indeed fairly complex (and it's fun to consider when both are implemented ;-), but less of concern for tracing JIT engines because you can have efficient type-specialized implementations for most cases. Type specialization in Python is not that huge win...
  - Sesse__ 3y ago
    Also, you have craziness like quite regular iteration being implemented using exceptions, which are not exactly trivial to optimize.
    - lifthrasiir 3y ago
      If you want to be return absolutely any value from an iterator, an exception is indeed a reasonable choice though. Python generators came in much later, unlike JS for example.

sp332 3y ago

The last couple of CPython versions have had dramatic speed improvements, so that demonstrates your point but also gives some hope that things are changing on that front.

coldtea 3y ago
Dramatic? Barely. Even less than half of the non-dramatic speed improvements they promised. The promise was like "5 times faster in the next 4 releases", and the improvements in 2 releases thus far was like 20% at best (so not even 2x faster). Compared to JS pre-and-after modern engines it's a tiny improvement.

mseepgood 3y ago

If this is by design and it optimizes for simplicity and easy interoperability with C, why would you assess its quality as 'good software' based on criteria that are non-goals?

Asraelite 3y ago
In my eyes, "good software" does not necessarily just mean something that accomplishes its goals. You can set a goal of being bad, and that's kind of what CPython is doing. Of course, "good" and "bad" are relative. If you don't care about performance then there's nothing wrong with CPython.
- acqq 3y ago
  I agree with that estimate, I think it was really the idea of Python to be less than "good" by design. I mean one doesn't need more than: >>> exit Use exit() or Ctrl-D (i.e. EOF) to exit to see. They have that special handling, but they still don't want to let you out, because... IMO, they just want to be annoying. When a solution could be something like: Note: exit() is needed in scripts. In this prompt Ctrl-D (i.e. EOF) can also be used. Exiting.
  - heyodai 3y ago
    Yeah, that message is a pet peeve of mine. Like, you know what I'm trying to do.
    - Smaug123 3y ago
      It sort of doesn't! It's just doing exactly the same thing it would do with any other identifier: it's printing its `repr`. Try `repr(exit)`!
      - a1369209993 3y ago
        More to the point, try `[len,exit,repr]`. Consider what would happen if `exit.__repr__()` did terminate the program.

zitterbewegung 3y ago

I don't disagree with you but, now you can retrofit a JIT into python. https://blog.pyston.org/2022/09/29/announcing-3-7-3-10-support-and-a-new-direction/ https://blog.pyston.org/2022/09/29/announcing-3-7-3-10-suppo...

acqq 3y ago
"We think of the breakdown roughly as follows: of our roughly 30% original speedup, 10% is going into Pyston-lite, 10% was done independently by the CPython team between 3.8 and main, and the remaining 10% we are hoping to contribute back upstream." To compare with Javascript: if I remember, as it appeared, V8 JIT was orders of magnitude faster, compared to the interpreted code.
- zitterbewegung 3y ago
  There was also a bunch of effort being put into efficiency of JavaScript. But now the tables have been changed and Microsoft is putting a large amount of effort into Python .

heavyset_go 3y ago

Recent CPython development has been towards optimizations and addressing use cases that benefit from optimizations, some coming from the faster CPython initiative. You might just get your JIT[1]. At the same time, I also agree with your sentiment. [1] https://github.com/faster-cpython/ideas/wiki/Workflow-for-3.12-cycle#trace-optimized-interpreter https://github.com/faster-cpython/ideas/wiki/Workflow-for-3....

nostrademons 3y ago

It's great software for the use case that Python is intended for. Python is supposed to be glue code. You embed a scripting runtime in your application, do all the heavy lifting in C, but configure your building blocks in Python so that you can easily reconfigure them as needs change. NumPy, SciPy, TensorFlow, PyTorch, JAX, Pandas, Pillow, lxml, cjson, PyCapnP, Tornado, fast-avro, etc. all get it right. They are wrappers around C (or in some cases: Fortran/assembly/CUDA) code, where the overflow of Python method dispatch is dwarfed by the hundreds of thousands of iterations of an inner loop that's in optimized, vectorized assembly. Django, Protobufs, and Avro get it wrong (often for portability or developer velocity sake), where they wrote the whole library in Python at the expense of performance. I was briefly tempted to write an API-compatible reimplementation of Django with the core in C++ when I left Google, but by then Django (and server-side web programming) was already falling out of favor, and if you're just shipping JSON to a SPA you can use cjson with any number of fast wsgi or asgi gateways.

bb88 3y ago
I've been playing around with HTMX with Django, and it seems simple enough for server side rendering. It works well with the Django templating system. I feel like as an industry we should step back and take a serious look at front end frameworks from first principles. One aspect that's clear to me, is that we should make modifications to HTML to support HTMX like transactions.
oivey 3y ago
Arguably no one’s goal is to glue pieces of C together. That’s too abstract. Their goal is to do something like write a performant web server, maybe easily and quickly. Python’s approach is one way to do that, but there are other ways that might be better. Having to write code in two languages to solve a problem, one of which that is difficult to write and has lots of footguns, has some clear downsides.
- nerdponx 3y ago
  Ritchie and Thompson might disagree with you.
- 3y ago

matheusmoreira 3y ago

Just yesterday I compared the small language I created to Python. Was surprised my tree walking interpreter somehow beat Python's bytecode virtual machine at recursive Fibonacci. It was just a simple hyperfine benchmark so I might be confounding code execution performance with the initialization time. Still caught me totally off guard and gave me a huge confidence and motivation boost. I was thinking something like "OK let's see just how bad this thing is" but it actually beat Python at something.

genman 3y ago

I really enjoined working in Lua.

ouraf 3y ago

Is there any comprehensive comparison and benchmark of intepreted languages or languages with a REPL and analysis of how each interpreter handles common operations?