3 ms·

If JIT is a good thing for Python, why don't just compile to Java or .NET bytecode and use their already optimized infrastructure?

crabbone 3y ago
Given how many Microsoft employees today steer the Python decision making process, I'm sure in not so distant future, we might see a new CLR-based Python implementation. Maybe Microsoft don't know yet how to sell this thing, or maybe they are just boiling the frog. Time will tell. But I'm pretty sure your question will be repeated as soon as people will get used to the idea of Python on JIT.
- _bohm 3y ago
  Doesn't this already exist in IronPython?
  - Timothycquinn 3y ago
    Correct. I just checked the project yesterday and they are presently at 3.4 :-|
  - crabbone 3y ago
    It's a lot about popularity / stigma. Microsoft developed both JScript and Node.js. They could've continued with JScript, but obviously decided against it because JScript didn't earn the reputation they might have hoped for. Even if they invested efforts into rectifying the flaws of JScript, it would've been just too hard to undo the reputation damage. Microsoft made multiple attempts to "befriend" Python. IronPython was one of the failures. They also tried to provide editing tools (eg. intellisense in MSVS), but kind of given up on that too (but succeeded to a large degree with VSCode). The whole long-term Microsoft's strategy is to capture and put the developers on a leash. They won't rest until there's a popular language they don't control.
- Gollapalli 3y ago
  “Python code runs 15% faster and and 20% cheaper on azure than aws, thanks to our optimized azurePython runtime. Use it for azure functions and ml training” Just a guess at the pitch.
  - robben1234 3y ago
    How much of Python in the world is ran on Azure? It's my language of preference and the main professional one, along with JS/TS and Go. But if they pulled something like this I'm pretty sure I'd reluctantly pack things up and move to Go.
- seabrookmx 3y ago
  It exists, was created by microsoft employees, and is referenced in the article: https://www.trypyjion.com/ https://www.trypyjion.com/
dbrueck 3y ago
If you're interested in learning more about the challenges and tradeoffs, both Jython (https://www.jython.org/ https://www.jython.org/) and IronPython (https://ironpython.net/ https://ironpython.net/) have been around for a long time and there's a lot of reading material on that subject.
- _ea1k 3y ago
  Graal Python exists too: https://www.graalvm.org/python/ https://www.graalvm.org/python/ It beats Python on performance, supposedly, but compatibility has never been great.
  - SpaghettiCthulu 3y ago
    I've found the startup time for Graal Python to be terrible compared with other Graal languages like JS. When I did some profiling, it seemed that the vast majority of the time was spent loading the standard library. If implemented lazily, that should have a negligible performance impact.
monlockandkey 3y ago
This is what you are looking for. Python on the GraalVM https://github.com/oracle/graalpython https://github.com/oracle/graalpython
deleted 3y ago
[deleted]
rogerbinns 3y ago
Python is a convenient friendly syntax for calling code implemented in C. While you can easily re-implement the syntax, you then have to decide how much of that C to re-implement. A few of the builtin types are easy (eg strings and lists), but it soon becomes a mountain of code and interoperability, especially if you want to get the semantics exactly right. And that is just the beginning - a lot of the value of Python is in the extensions, and many popular ones (eg numpy, sqlite3) are implemented in C and need to interoperate with your re-implementation. Trying to bridge from Java or .NET to those extensions will overwhelm any performance advantages you got. This JIT approach is improving the performance of bits of the interpreter while maintaining 100% compatibility with the rest of the C code base, its object model, and all the extensions.
seabrookmx 3y ago
This is referenced in the article: > The big downside with a “full” JIT is that the process of compiling once into IL and then again into machine code is slow. Not only is it slow, but it is memory intensive.

crabbone 3y ago

Given how many Microsoft employees today steer the Python decision making process, I'm sure in not so distant future, we might see a new CLR-based Python implementation. Maybe Microsoft don't know yet how to sell this thing, or maybe they are just boiling the frog. Time will tell. But I'm pretty sure your question will be repeated as soon as people will get used to the idea of Python on JIT.

_bohm 3y ago
Doesn't this already exist in IronPython?
- Timothycquinn 3y ago
  Correct. I just checked the project yesterday and they are presently at 3.4 :-|
- crabbone 3y ago
  It's a lot about popularity / stigma. Microsoft developed both JScript and Node.js. They could've continued with JScript, but obviously decided against it because JScript didn't earn the reputation they might have hoped for. Even if they invested efforts into rectifying the flaws of JScript, it would've been just too hard to undo the reputation damage. Microsoft made multiple attempts to "befriend" Python. IronPython was one of the failures. They also tried to provide editing tools (eg. intellisense in MSVS), but kind of given up on that too (but succeeded to a large degree with VSCode). The whole long-term Microsoft's strategy is to capture and put the developers on a leash. They won't rest until there's a popular language they don't control.
Gollapalli 3y ago
“Python code runs 15% faster and and 20% cheaper on azure than aws, thanks to our optimized azurePython runtime. Use it for azure functions and ml training” Just a guess at the pitch.
- robben1234 3y ago
  How much of Python in the world is ran on Azure? It's my language of preference and the main professional one, along with JS/TS and Go. But if they pulled something like this I'm pretty sure I'd reluctantly pack things up and move to Go.
seabrookmx 3y ago
It exists, was created by microsoft employees, and is referenced in the article: https://www.trypyjion.com/ https://www.trypyjion.com/

dbrueck 3y ago

If you're interested in learning more about the challenges and tradeoffs, both Jython (https://www.jython.org/ https://www.jython.org/) and IronPython (https://ironpython.net/ https://ironpython.net/) have been around for a long time and there's a lot of reading material on that subject.

_ea1k 3y ago
Graal Python exists too: https://www.graalvm.org/python/ https://www.graalvm.org/python/ It beats Python on performance, supposedly, but compatibility has never been great.
- SpaghettiCthulu 3y ago
  I've found the startup time for Graal Python to be terrible compared with other Graal languages like JS. When I did some profiling, it seemed that the vast majority of the time was spent loading the standard library. If implemented lazily, that should have a negligible performance impact.

monlockandkey 3y ago

This is what you are looking for. Python on the GraalVM https://github.com/oracle/graalpython https://github.com/oracle/graalpython

deleted 3y ago

[deleted]

rogerbinns 3y ago

Python is a convenient friendly syntax for calling code implemented in C. While you can easily re-implement the syntax, you then have to decide how much of that C to re-implement. A few of the builtin types are easy (eg strings and lists), but it soon becomes a mountain of code and interoperability, especially if you want to get the semantics exactly right. And that is just the beginning - a lot of the value of Python is in the extensions, and many popular ones (eg numpy, sqlite3) are implemented in C and need to interoperate with your re-implementation. Trying to bridge from Java or .NET to those extensions will overwhelm any performance advantages you got. This JIT approach is improving the performance of bits of the interpreter while maintaining 100% compatibility with the rest of the C code base, its object model, and all the extensions.

seabrookmx 3y ago

This is referenced in the article: > The big downside with a “full” JIT is that the process of compiling once into IL and then again into machine code is slow. Not only is it slow, but it is memory intensive.