4 ms·
> because CPython aims to be relatively simple and straightforward by choice Sacrificing performance for core interpreter developer convenience may have been t
by 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 agoWe 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 agoThanks for the context, those are great points.