4 ms·

The primary reason, in my opinion, is the vast majority of Python libraries lack type annotations (this includes the standard library). Without type annotations

The primary reason, in my opinion, is the vast majority of Python libraries lack type annotations (this includes the standard library). Without type annotations, there is very little for a non-JIT compiler to optimize, since: - The vast majority of code generation would have to be dynamic dispatches, which would not be too different from CPython's bytecode. - Types are dynamic; the methods on a type can change at runtime due to monkey patching. As a result, the compiler must be able to "recompile" a type at runtime (and thus, you cannot ship optimized target files). - There are multiple ways every single operation in Python might be called; for instance `a.b` either does a __dict__ lookup or a descriptor lookup, and you don't know which method is used unless you know the type (and if that type is monkeypatched, then the method that called might change). A JIT compiler might be able to optimize some of these cases (observing what is the actual type used), but a JIT compiler can use the source file/be included in the CPython interpreter.

hwpythonner 1y ago
You make a great point — type information is definitely a huge part of the challenge. I'd add that even beyond types, late binding is fundamental to Python’s dynamism: Variables, functions, and classes are often only bound at runtime, and can be reassigned or modified dynamically. So even if every object had a type annotation, you would still need to deal with names and behaviors changing during execution — which makes traditional static compilation very hard. That’s why PyXL focuses more on efficient dynamic execution rather than trying to statically "lock down" Python like C++.
pjmlp 1y ago
Solved by Smalltalk, Self, and Lisp JITs, that are in the genesis of JIT technology, some of it landed on Hotspot and V8.
- jonathaneunice 1y ago
  "Addressed" or "mitigated" perhaps. Not "solved." Just "made less painful" or "enough less painful that we don't need to run screaming from the room."
  - pjmlp 1y ago
    Versus what most folks do with CPython, it is indeed solved. We are very far from having a full single user graphics workstation in CPython, even if those JITs aren't perfect. Yes, there are a couple of ongoing attempts, while most in the community rather write C extensions.
    - Qem 1y ago
      > We are very far from having a full single user graphics workstation in CPython, even if those JITs aren't perfect. Some years ago there was an attempt to create a linux distribution including a Python userspace, called Snakeware. But the project went inactive since then. See https://github.com/joshiemoore/snakeware https://github.com/joshiemoore/snakeware
      - pjmlp 1y ago
        I fail to find anything related to have a good enough performance for a desktop system written in Python.
      - homarp 1y ago
        Sugar is built with python https://github.com/sugarlabs/sugar https://github.com/sugarlabs/sugar
    - jonathaneunice 1y ago
      Is "single user graphics workstation" even still a goal? Great target in the Early to Mid Ethernetian when Xerox Dorados and Dandelions, Symbolics, and Liliths roamed the Earth. Doesn't feel like a modern goal or standard of comparison. I used those workstations back in the day—then rinsed and repeated with JITs and GCs for Self, Java, and on to finally Python in PyPy. They're fantastic! Love having them on-board. Many blessings to Deutsch, Ungar, et al. But for 40 years JIT's value has always been to optimize away the worst gaps, getting "close enough" to native to preserve "it's OK to use the highest level abstractions" for an interesting set of workloads. A solid success, but side by side with AOT compilation of closer-to-the-machine code? AOT regularly wins, then and now. "Solved" should imply performance isn't a reason to utterly switch languages and abstractions. Yet witness the enthusiasm around Julia and Rust e.g. specifically to get more native-like performance. YMMV, but from this vantage, seeing so much intentional down-shift in abstraction level and ecosystem maturity "for performance" feels like JIT reduced but hardly eliminated the gap.
- dragonwriter 1y ago
  Python starting with 3.13 also has a JIT available.
  - pjmlp 1y ago
    Kind of, you have to compile it yourself, and is rather basic, still early days. PyPy and GraalPy is where the fun is, however they are largely ignored outside their language research communities.
Qem 1y ago
> The primary reason, in my opinion, is the vast majority of Python libraries lack type annotations (this includes the standard library). When type annotations are available, it's already possible to compile Python to improve performance, using Mypyc. See for example https://blog.glyph.im/2022/04/you-should-compile-your-python-and-heres-why.html https://blog.glyph.im/2022/04/you-should-compile-your-python...

hwpythonner 1y ago

You make a great point — type information is definitely a huge part of the challenge. I'd add that even beyond types, late binding is fundamental to Python’s dynamism: Variables, functions, and classes are often only bound at runtime, and can be reassigned or modified dynamically. So even if every object had a type annotation, you would still need to deal with names and behaviors changing during execution — which makes traditional static compilation very hard. That’s why PyXL focuses more on efficient dynamic execution rather than trying to statically "lock down" Python like C++.

pjmlp 1y ago

Solved by Smalltalk, Self, and Lisp JITs, that are in the genesis of JIT technology, some of it landed on Hotspot and V8.

jonathaneunice 1y ago
"Addressed" or "mitigated" perhaps. Not "solved." Just "made less painful" or "enough less painful that we don't need to run screaming from the room."
- pjmlp 1y ago
  Versus what most folks do with CPython, it is indeed solved. We are very far from having a full single user graphics workstation in CPython, even if those JITs aren't perfect. Yes, there are a couple of ongoing attempts, while most in the community rather write C extensions.
  - Qem 1y ago
    > We are very far from having a full single user graphics workstation in CPython, even if those JITs aren't perfect. Some years ago there was an attempt to create a linux distribution including a Python userspace, called Snakeware. But the project went inactive since then. See https://github.com/joshiemoore/snakeware https://github.com/joshiemoore/snakeware
    - pjmlp 1y ago
      I fail to find anything related to have a good enough performance for a desktop system written in Python.
    - homarp 1y ago
      Sugar is built with python https://github.com/sugarlabs/sugar https://github.com/sugarlabs/sugar
  - jonathaneunice 1y ago
    Is "single user graphics workstation" even still a goal? Great target in the Early to Mid Ethernetian when Xerox Dorados and Dandelions, Symbolics, and Liliths roamed the Earth. Doesn't feel like a modern goal or standard of comparison. I used those workstations back in the day—then rinsed and repeated with JITs and GCs for Self, Java, and on to finally Python in PyPy. They're fantastic! Love having them on-board. Many blessings to Deutsch, Ungar, et al. But for 40 years JIT's value has always been to optimize away the worst gaps, getting "close enough" to native to preserve "it's OK to use the highest level abstractions" for an interesting set of workloads. A solid success, but side by side with AOT compilation of closer-to-the-machine code? AOT regularly wins, then and now. "Solved" should imply performance isn't a reason to utterly switch languages and abstractions. Yet witness the enthusiasm around Julia and Rust e.g. specifically to get more native-like performance. YMMV, but from this vantage, seeing so much intentional down-shift in abstraction level and ecosystem maturity "for performance" feels like JIT reduced but hardly eliminated the gap.
dragonwriter 1y ago
Python starting with 3.13 also has a JIT available.
- pjmlp 1y ago
  Kind of, you have to compile it yourself, and is rather basic, still early days. PyPy and GraalPy is where the fun is, however they are largely ignored outside their language research communities.

Qem 1y ago

> The primary reason, in my opinion, is the vast majority of Python libraries lack type annotations (this includes the standard library). When type annotations are available, it's already possible to compile Python to improve performance, using Mypyc. See for example https://blog.glyph.im/2022/04/you-should-compile-your-python-and-heres-why.html https://blog.glyph.im/2022/04/you-should-compile-your-python...