Python 3.11 Performance Benchmarks Show Huge Improvement

[sinepgib]

Yeah, though removing GIL would at least make it possible to scale up the application and sometimes hide other inefficiencies.
Sometimes this might be good enough.

I'd say in most cases where it's currently used, yes. I was not trying to say it would be useless, just that we often put too much of the blame on it when it only hurts parallelism.

And yes, the GIL simplifies the python interpreter, supports multithreading without hurting single-thread speed.
IMO removing it probably requires JIT or some new language constructs.

Yes, it's not there by accident after all. Regarding requirements, I don't think it requires JIT nor changing the high level part of the language. It will probably require breaking the C API to some degree, and it will either require more sophisticated techniques for reference counting, a hit for simply taking locks or promoting the GC to be the only memory management mechanism.

[sinepgib]

If you implement an emulator of an 8-bit machine (such as: Atari 130XE) and compile the emulator using an AOT compiler, then it is mathematically impossible for the AOT compiler to account for the fact that you loaded a a particular game (such as: Bruce Lee) into the 8-bit emulator, especially if it is a game that was developed after the file "Atari130XE.exe" was created by the AOT compiler. ---- If the emulator was implemented in Python (or some other language capable of compiling and loading arbitrary code at run-time) then the emulator could translate selected parts of the currently loaded 8-bit machine-code directly into Python bytecode.

A (probably) better approach remains being mixing both by embedding a JIT compiler into your AOT program. Now, your example is flawed because Python is only particularly good at dynamically evaluating Python code. Implementing a JIT for the Atari 130XE can be done with whatever language, it doesn't really matter if you use Python or C or Lisp because what you really care about is the emitted code. If you were to implement it as a VM in Python it would still be slower than implementing it as a VM in C.
The case that typically suffers is stuff like Rust-in-Rust because the compile time of Rust is much larger than any tracing JIT will ever be.

[NobodyXu]

Yes, it's not there by accident after all. Regarding requirements, I don't think it requires JIT nor changing the high level part of the language. It will probably require breaking the C API to some degree, and it will either require more sophisticated techniques for reference counting, a hit for simply taking locks or promoting the GC to be the only memory management mechanism.

Yeah you are right.
Removing the GIL would certainly break the C API, reference counting/change to GC and requires to add lock somehow, thus probably requires new language construct.

[NobodyXu]

If you implement an emulator of an 8-bit machine (such as: Atari 130XE) and compile the emulator using an AOT compiler, then it is mathematically impossible for the AOT compiler to account for the fact that you loaded a a particular game (such as: Bruce Lee) into the 8-bit emulator, especially if it is a game that was developed after the file "Atari130XE.exe" was created by the AOT compiler. ---- If the emulator was implemented in Python (or some other language capable of compiling and loading arbitrary code at run-time) then the emulator could translate selected parts of the currently loaded 8-bit machine-code directly into Python bytecode.

In order for that python program to account for that "Atari130XE.exe" and specialize for it, you must implement the python code requires for identifying that program and add that specialized treatment when you are writing that python program.
Which means that you already put the information into the program before it even starts running.

Then, what's the problem with doing the same thing with AOT program?
You already put the information into the python program prior to running it, you can absolutely do the same thing in AOT program.

You see, AOT is not inferior to dynamic language, the later does not give you more advantages when it comes to such optimization or the general ease-of-use since every case would still needs to be coded AOT before the program is up and running.

[sinepgib]

Yeah you are right.
Removing the GIL would certainly break the C API, reference counting/change to GC and requires to add lock somehow, thus probably requires new language construct.

None of those are visible to pure Python code. In fact, aren't some of the alternative interpreters GIL-less? I may be confused, but I think IronPython or Jython don't have a GIL, and pure Python is supposed to run fine. Maybe we mean different things with "language construct"? I interpret a syntax/semantic change at the Python language level (i.e., I'm not counting changes to native extensions, those will surely break and are not always compatible between implementations).

[NobodyXu]

None of those are visible to pure Python code. In fact, aren't some of the alternative interpreters GIL-less? I may be confused, but I think IronPython or Jython don't have a GIL, and pure Python is supposed to run fine. Maybe we mean different things with "language construct"? I interpret a syntax/semantic change at the Python language level (i.e., I'm not counting changes to native extensions, those will surely break and are not always compatible between implementations).

I was mainly thinking about locking.
IMHO if GIL is removed, then having some language construct for locking might be desired, probably because I come from compiled PL like Rust and is used to explicitly add locking.
I have not looked too much into IronPython or Jython, though I do hear that they do not have a GIL due to different API and JIT.

[marios]

[*]Because neither compile() nor eval() are in the C/C++ standards, it is possible that a high-performance 8-bit emulator could run faster in plain CPython than in plain C/C++. The term "plain C/C++" means that the main part of the emulator isn't using non-standard C/C++ features (such as: libgccjit.so).

What are you talking about? libgccjit.so is neither a C nor C++ feature. It is a shared object accompanied by some .h files just like every C dynamic library. And the ability to use libraries is definitely part of both C and C++ standard. And code that includes those .h files and uses the functionality is perfectly compliant to the standard. The fact that it is not built in the syntax of the language is good practice.

[NobodyXu]

It isn't necessary because it is possible to search the space for near-optimal solutions without human intervention during the search.

And in order for the python program to search the space, you would have to write the algorithm first before the program is started, which can also be done in AOT PL.

A trivial example would be the CPython interpreter itself.
Since it accepts almost all valid python code and is written in C, an AOT pl, it can be considered as a C program that takes file "*.py" as data.
Since python is interpreted by the C program, anything can be done by the python must be able to be done by C.

[NobodyXu]

[*]Because neither compile() nor eval() are in the C/C++ standards, it is possible that a high-performance 8-bit emulator could run faster in plain CPython than in plain C/C++. The term "plain C/C++" means that the main part of the emulator isn't using non-standard C/C++ features (such as: libgccjit.so).

Does it matter?
You can write a C/C++/Rust interpreter or a JIT compiler that compiles C/C++/Rust to some internal bitcode or to native code and run them anyway.

The "compile()" function in python also calls into the python interpreter written in C, it's not written in Python.

[sinepgib]

I was mainly thinking about locking.
IMHO if GIL is removed, then having some language construct for locking might be desired, probably because I come from compiled PL like Rust and is used to explicitly add locking.
I have not looked too much into IronPython or Jython, though I do hear that they do not have a GIL due to different API and JIT.

Python already has mutex and rwlock in its standard library IIRC. That's because the GIL only prevents races at the individual opcode level, not complex objects.