4 ms·

> An interpreter with a JIT is obviously faster than one without. And why doesn't python's default runtime environment obviously come with a JIT then? I think

> An interpreter with a JIT is obviously faster than one without. And why doesn't python's default runtime environment obviously come with a JIT then? I think they should absolutely go for it, given the huge user base of python. Reasons like "but named functions can dynamically change" are not applicable, since JS has those same properties and can do it. They could start with optimizing the case where you call the same function over and over in a for loop. An alternative python interpreter is also not the solution, normally what you have is the main standard python interpreter, and that is the one that should be fast, period.

masklinn 6y ago
> And why doesn't python's default runtime environment come with JIT? I think they should absolutely go for it, ensure the default python you get when you run python has a JIT, given the huge user base of python. 1. because CPython aims to be relatively simple and straightforward by choice 2. because the "huge user base" comes in large parts from the deep and extensive C API, which is absolute hell on a JIT 3. because most of the userbase would not give a shit anyway, it has not exactly migratd en masse to pypy: much of the userbase sees and uses Python as a glue language, Python is an interface to optimised C routines without being a pain in the ass to develop in.
- Aardwolf 6y ago
  > 1. because CPython aims to be relatively simple and straightforward by choice It's a painful choice, and having to use numpy for everything that a loop normally could do but is too slow for, or discourage making functions because a function call is so slow, makes an otherwise elegant language less so
- ak217 6y ago
  > because CPython aims to be relatively simple and straightforward by choice Sacrificing performance for core interpreter developer convenience may have been the right choice when Python was getting started; it's no longer the right choice today. Today it's short-sighted. > because the "huge user base" comes in large parts from the deep and extensive C API, which is absolute hell on a JIT We can have both a JIT and a "deep and extensive" (or more importantly, stable) native API, as demonstrated by node. > because most of the userbase would not give a shit anyway Actually a lot of the userbase don't use libraries with native extensions, are painfully aware of Python's performance issues, and are intensely interested in addressing them.
  - thu2111 6y ago
    We can have both a JIT and a "deep and extensive" (or more importantly, stable) native API, as demonstrated by node. Yes, but not that native API. Designing a native API that doesn't create huge problems later is difficult. The JVM, .NET and V8 guys managed it (mostly) but the scripting languages generally didn't. Their API is just literally the entire internals of the interpreter. Figuring out how to JIT code in the presence of native extensions that expect the implementation to work in exactly the same way it always worked is a research problem. The only people who have got close to solving it are the GraalVM guys. They do it by virtualising the interpreter API and also JIT-compiling the C code! They run LLVM bitcode on the same engine that runs the scripting engine.
    - ak217 6y ago
      Thanks for the context, those are great points.
nemothekid 6y ago
Armin Ronacher, author Flask, actually has a good talk about this. The gist of it the way Python's internals leak into the language makes it very difficult to build a performant JIT that wouldn't break a large amount of userspace code. Python lets you do _far_ more shenanigans that Javascript does; and a lot of large libraries depend on some of that behavior. Breaking it would probably cause a new 2 -> 3 situation. https://www.youtube.com/watch?v=qCGofLIzX6g&feature=emb_title https://www.youtube.com/watch?v=qCGofLIzX6g&feature=emb_titl...
- ak217 6y ago
  > a lot of large libraries depend on some of that behavior. Armin makes great points about path dependence of API design and how the CPython API leaks into the Python language spec. But the features being discussed are actually obscure (example: slots) or intended for debugging (example: frame introspection), and most libraries don't have a good reason to use them. We're stuck in a loop: people talk about how Python is special and can't use a JIT because its internals are not JIT-friendly, so we don't have a JIT, so implementers continue to make choices that are not JIT-friendly - not because they want to, but because they have no guidance. The JIT doesn't have to be amazing on day 1. What it does have to do is show a commitment and a path to performant code, and illuminate situations where optimizations turn off. There's nothing fundamental in Python's design that prevents a JIT from working; a small number of rarely used dynamic features (that most people don't know about and don't know that they can negatively affect performance) should not be used to hold up interpreter design.
  - thu2111 6y ago
    GraalPython is on its way to solving this, by co-JIT-compiling both Python and the code of the native extensions simultaneously. However Python is a large language and ecosystem, so it'll take a while for the implementation to mature.
- Sohcahtoa82 6y ago
  > Python lets you do _far_ more shenanigans that Javascript does Does JavaScript let you do this monstrosity of terrible code? Python 3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 23:09:28) [MSC v.1916 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class Dog(object): ... def speak(self): ... print("bark!") ... >>> class Cat(object): ... def speak(self): ... print("meow!") ... >>> animal = Dog() >>> animal.speak() bark! >>> animal.__class__ = Cat >>> animal.speak() meow! >>>

masklinn 6y ago

> And why doesn't python's default runtime environment come with JIT? I think they should absolutely go for it, ensure the default python you get when you run python has a JIT, given the huge user base of python. 1. because CPython aims to be relatively simple and straightforward by choice 2. because the "huge user base" comes in large parts from the deep and extensive C API, which is absolute hell on a JIT 3. because most of the userbase would not give a shit anyway, it has not exactly migratd en masse to pypy: much of the userbase sees and uses Python as a glue language, Python is an interface to optimised C routines without being a pain in the ass to develop in.

Aardwolf 6y ago
> 1. because CPython aims to be relatively simple and straightforward by choice It's a painful choice, and having to use numpy for everything that a loop normally could do but is too slow for, or discourage making functions because a function call is so slow, makes an otherwise elegant language less so
ak217 6y ago
> because CPython aims to be relatively simple and straightforward by choice Sacrificing performance for core interpreter developer convenience may have been the right choice when Python was getting started; it's no longer the right choice today. Today it's short-sighted. > because the "huge user base" comes in large parts from the deep and extensive C API, which is absolute hell on a JIT We can have both a JIT and a "deep and extensive" (or more importantly, stable) native API, as demonstrated by node. > because most of the userbase would not give a shit anyway Actually a lot of the userbase don't use libraries with native extensions, are painfully aware of Python's performance issues, and are intensely interested in addressing them.
- thu2111 6y ago
  We can have both a JIT and a "deep and extensive" (or more importantly, stable) native API, as demonstrated by node. Yes, but not that native API. Designing a native API that doesn't create huge problems later is difficult. The JVM, .NET and V8 guys managed it (mostly) but the scripting languages generally didn't. Their API is just literally the entire internals of the interpreter. Figuring out how to JIT code in the presence of native extensions that expect the implementation to work in exactly the same way it always worked is a research problem. The only people who have got close to solving it are the GraalVM guys. They do it by virtualising the interpreter API and also JIT-compiling the C code! They run LLVM bitcode on the same engine that runs the scripting engine.
  - ak217 6y ago
    Thanks for the context, those are great points.

nemothekid 6y ago

Armin Ronacher, author Flask, actually has a good talk about this. The gist of it the way Python's internals leak into the language makes it very difficult to build a performant JIT that wouldn't break a large amount of userspace code. Python lets you do _far_ more shenanigans that Javascript does; and a lot of large libraries depend on some of that behavior. Breaking it would probably cause a new 2 -> 3 situation. https://www.youtube.com/watch?v=qCGofLIzX6g&feature=emb_title https://www.youtube.com/watch?v=qCGofLIzX6g&feature=emb_titl...

ak217 6y ago
> a lot of large libraries depend on some of that behavior. Armin makes great points about path dependence of API design and how the CPython API leaks into the Python language spec. But the features being discussed are actually obscure (example: slots) or intended for debugging (example: frame introspection), and most libraries don't have a good reason to use them. We're stuck in a loop: people talk about how Python is special and can't use a JIT because its internals are not JIT-friendly, so we don't have a JIT, so implementers continue to make choices that are not JIT-friendly - not because they want to, but because they have no guidance. The JIT doesn't have to be amazing on day 1. What it does have to do is show a commitment and a path to performant code, and illuminate situations where optimizations turn off. There's nothing fundamental in Python's design that prevents a JIT from working; a small number of rarely used dynamic features (that most people don't know about and don't know that they can negatively affect performance) should not be used to hold up interpreter design.
- thu2111 6y ago
  GraalPython is on its way to solving this, by co-JIT-compiling both Python and the code of the native extensions simultaneously. However Python is a large language and ecosystem, so it'll take a while for the implementation to mature.
Sohcahtoa82 6y ago
> Python lets you do _far_ more shenanigans that Javascript does Does JavaScript let you do this monstrosity of terrible code? Python 3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 23:09:28) [MSC v.1916 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class Dog(object): ... def speak(self): ... print("bark!") ... >>> class Cat(object): ... def speak(self): ... print("meow!") ... >>> animal = Dog() >>> animal.speak() bark! >>> animal.__class__ = Cat >>> animal.speak() meow! >>>