7 ms·

I love me some Python, trust me. But this is just putting lipstick on a pig. The language needs to be rewritten from the ground up. If you’ve ever analyzed the

I love me some Python, trust me. But this is just putting lipstick on a pig. The language needs to be rewritten from the ground up. If you’ve ever analyzed the machine code a simple python script spits out you’ll see how helplessly bloated it is.

leetrout 3y ago
Do you have thoughts around the concept of Python becoming a Rust macro based language? I read another comment about that being a potential future for Python but I don't know how feasible it is. I've moved on to Go for things where I need to care about performance but like thinking about things in a similar way Python lets me think about them.
tredre3 3y ago
> If you’ve ever analyzed the machine code a simple python script spits out you’ll see how helplessly bloated it is. How would one do that? I thought python generated bytecode and interpreted that code? Where's the machine code? Do you mean dissembling the python interpreter itself? In which case it would be gcc/llvm spitting out machine code, no?
__d 3y ago
You can make a Python-ish language that can run fast (or at least, a lot faster) but it cannot be Python: the dynamic nature of the language means many optimizing techniques just aren't available. The unfortunate thing is that the vast majority of Python code in use today doesn't need all those super-dynamic features. So it would run just fine on a cut-down JITed interpreter. But there's always the corner cases. In retrospect, Python 3 was a lost opportunity here: it could have broken more compatibility, enabled multi-core and JITs, and then the 10 year transition pain would actually have been worth it. But that's hindsight, of course.
- fuc____d 3y ago
  [dead]
- chlorion 3y ago
  >the dynamic nature of the language means many optimizing techniques just aren't available. This is something that seems like it should be true, but counter evidence exists that proves that it's not the case. The first example would be V8, the JavaScript JIT compiler used in Chrome and NodeJs (and probably other things). V8 is many times faster than CPython in pretty much every situation. The second, and even better example is SBCL, a Common Lisp compiler. SBCL is quite a bit faster than CPython and V8, it's closer to the JVM in terms of performance in benchmarks that I have saw. The third example would be some of the Scheme compilers, like Chez and Gambit, which are not far off from SBCL. Maybe you could argue that JavaScript is not as dynamic as Python. I don't know JavaScript at all so maybe that is the case. I'm pretty sure that Common Lisp and Scheme are not less dynamic though. I think Common Lisp is actually more dynamic but I don't have any way to measure this, so it's just my opinion. So assuming these languages are as or more dynamic than Python, this seems to be proof that Pythons dynamic-ness is not the reason for it's poor performance! The Lisp compilers are also much less widely used and have much less engineering power available! I think these counter examples are pretty interesting and don't know exactly what to make of it. Python has more funding and more users to contribute to it (except in the case of V8), I guess until now they just haven't put any of that into performance.
  - kazinator 3y ago
    Python is "stupid dynamic"; it exposes implementation details which can't work work well under compilation, like accessing a caller's local variables.
    - chlorion 3y ago
      Yes, but Common Lisp is also "stupid dynamic"! I don't think there's anything Python can do that Common Lisp can't in terms of dynamic-ness! This is a quote from python.org: >These languages are close to Python in their dynamic semantics, but so different in their approach to syntax that a comparison becomes almost a religious argument: is Lisp's lack of syntax an advantage or a disadvantage? It should be noted that Python has introspective capabilities similar to those of Lisp, and Python programs can construct and execute program fragments on the fly. Usually, real-world properties are decisive: Common Lisp is big (in every sense), and the Scheme world is fragmented between many incompatible versions, where Python has a single, free, compact implementation. https://www.python.org/doc/essays/comparisons/ https://www.python.org/doc/essays/comparisons/ I believe there are dynamic things Common Lisp can do that python can't, like modifying and creating classes, inheritance and methods at runtime, even with effects propagating out to already existing class instances!
- pjmlp 3y ago
  Besides the sibling comment, Smalltalk and SELF JITs prove otherwise. Ongoing Ruby efforts as well.
  - __d 3y ago
    And yet, after 30 years of effort from various different, talented people and teams, with historical knowledge of eg, StrongTalk, and Self, and Common Lisp, and Java, and JavaScript, we've yet to see any major leaps in Python performance. So, in my opinion, it's clearly not as simple as just taking all of that existing knowledge and a good team and just doing it, or one of the many efforts to do so would almost certainly have succeeded by now.

leetrout 3y ago

Do you have thoughts around the concept of Python becoming a Rust macro based language? I read another comment about that being a potential future for Python but I don't know how feasible it is. I've moved on to Go for things where I need to care about performance but like thinking about things in a similar way Python lets me think about them.

tredre3 3y ago

> If you’ve ever analyzed the machine code a simple python script spits out you’ll see how helplessly bloated it is. How would one do that? I thought python generated bytecode and interpreted that code? Where's the machine code? Do you mean dissembling the python interpreter itself? In which case it would be gcc/llvm spitting out machine code, no?

__d 3y ago

You can make a Python-ish language that can run fast (or at least, a lot faster) but it cannot be Python: the dynamic nature of the language means many optimizing techniques just aren't available. The unfortunate thing is that the vast majority of Python code in use today doesn't need all those super-dynamic features. So it would run just fine on a cut-down JITed interpreter. But there's always the corner cases. In retrospect, Python 3 was a lost opportunity here: it could have broken more compatibility, enabled multi-core and JITs, and then the 10 year transition pain would actually have been worth it. But that's hindsight, of course.

fuc____d 3y ago
[dead]
chlorion 3y ago
>the dynamic nature of the language means many optimizing techniques just aren't available. This is something that seems like it should be true, but counter evidence exists that proves that it's not the case. The first example would be V8, the JavaScript JIT compiler used in Chrome and NodeJs (and probably other things). V8 is many times faster than CPython in pretty much every situation. The second, and even better example is SBCL, a Common Lisp compiler. SBCL is quite a bit faster than CPython and V8, it's closer to the JVM in terms of performance in benchmarks that I have saw. The third example would be some of the Scheme compilers, like Chez and Gambit, which are not far off from SBCL. Maybe you could argue that JavaScript is not as dynamic as Python. I don't know JavaScript at all so maybe that is the case. I'm pretty sure that Common Lisp and Scheme are not less dynamic though. I think Common Lisp is actually more dynamic but I don't have any way to measure this, so it's just my opinion. So assuming these languages are as or more dynamic than Python, this seems to be proof that Pythons dynamic-ness is not the reason for it's poor performance! The Lisp compilers are also much less widely used and have much less engineering power available! I think these counter examples are pretty interesting and don't know exactly what to make of it. Python has more funding and more users to contribute to it (except in the case of V8), I guess until now they just haven't put any of that into performance.
- kazinator 3y ago
  Python is "stupid dynamic"; it exposes implementation details which can't work work well under compilation, like accessing a caller's local variables.
  - chlorion 3y ago
    Yes, but Common Lisp is also "stupid dynamic"! I don't think there's anything Python can do that Common Lisp can't in terms of dynamic-ness! This is a quote from python.org: >These languages are close to Python in their dynamic semantics, but so different in their approach to syntax that a comparison becomes almost a religious argument: is Lisp's lack of syntax an advantage or a disadvantage? It should be noted that Python has introspective capabilities similar to those of Lisp, and Python programs can construct and execute program fragments on the fly. Usually, real-world properties are decisive: Common Lisp is big (in every sense), and the Scheme world is fragmented between many incompatible versions, where Python has a single, free, compact implementation. https://www.python.org/doc/essays/comparisons/ https://www.python.org/doc/essays/comparisons/ I believe there are dynamic things Common Lisp can do that python can't, like modifying and creating classes, inheritance and methods at runtime, even with effects propagating out to already existing class instances!
pjmlp 3y ago
Besides the sibling comment, Smalltalk and SELF JITs prove otherwise. Ongoing Ruby efforts as well.
- __d 3y ago
  And yet, after 30 years of effort from various different, talented people and teams, with historical knowledge of eg, StrongTalk, and Self, and Common Lisp, and Java, and JavaScript, we've yet to see any major leaps in Python performance. So, in my opinion, it's clearly not as simple as just taking all of that existing knowledge and a good team and just doing it, or one of the many efforts to do so would almost certainly have succeeded by now.