https://stefan-marr.de/2023/06/...

Fascinating.

@Demolishun pypy doesnt have GIL right?

Not entirely sure how we came to GIL....

https://doc.pypy.org/en/latest/...

PyPy has a GIL.

https://peps.python.org/pep-0703/

The GIL removal is happening though.

In baby steps, by making it first optional, but it's happening.

The trouble with the removal is that it is one of these "bomb the foundation away and let's see what's happening" kind of changes. The GIL is what made large parts of Python thread safe "by design" - as they couldn't be used by multiple threads.

Removing the lock means one now has to apply thread safety "by code". No more global lock means that a lot of code could now be accessed by multiple threads...

@Demolishun yes.

Though that is part of the problem (Trademark).

Multithreading / Multiprocessing is a manual intervention to circumvent the problem.

"if" python would be multithreaded by default, the general performance on multicore machines should be better by default - at the cost of a worse single core performance.

Single core designs have become "rare" - almost nonexistent.

While I understand the concerns of the Python Devs, I think it's overdue.

I don't think we will get back to single core machines - forever... The paradigm of single core designs is dead.

Time to bury the program paradigms, too.

@Demolishun bad wording.

I meant the coding paradigms.

A global lock was once a common coding paradigm as "SMP (Symmetric MultiProcessing) platforms are rare unicorns"...

Well. For 20 years plus, these rare unicorns are the norm, so we shouldn't use the coding paradigm of global locks anymore...

Programming paradigm - coding paradigm.