Python GIL removal question

EDIT: Also, "stop whatever they are doing to synchronize the dirty cache lines with RAM," is not a very good way to describe what is going on, often times you don't have to hit RAM at all, the caches just synchronize between each other. It is still pretty bad for performance though.

I don't think it would. If there is a GIL (Global Interpreter Lock) only one thread of the process can be scheduled to run at any time. As the poster (Sturla) says, Python threads are native OS threads so they should be scheduled by the OS kernel (right?). A good scheduler would use affinity scheduling and schedule all threads of the Python program on the same processor/core every time to get benefits from cached data and code. I believe modern kernels (Linux, MacOS, Solaris, probably Windows as well) use this kind of affinity scheduling, so if we're lucky the Python process gets scheduled on the same processor every time and there will be no need any cache synchronization.

> I'm not a hardware expert, but I'm not sure how constant locking would prevent cache synchronization just because they weren't truly running in parallel.

I'm not sure if you misunderstood the mail. The constant locking would only be used if they were running in parallel.

Anyway, if you have a GIL you don't need that kind of locking described in the mail. You only need to do explicit locking on shared data structures when you read or update the contents of those data structures. If you have reference counting, threads that run in parallel and no GIL you would have to lock even if you are just assigning a reference to such a data structure to a new variable. If you have a GIL you are certain that only one thread at a time are updating the reference count. That is indeed what the GIL is, one coarse lock for all data (and the interpreter) instead of fine grained locks for every data structure.

(I don't know Python very well, I just answer from general knowledge of computer architecture and language implementation. But I've read about the Python GIL several times, since it's the most discussed GIL of any language.)

http://www.artima.com/weblogs/viewpost.jsp?thread=214235

Perhaps, but thanks to numpy, scipy and a host of other amazing libraries it still ties with matlab as the go to language for number crunching among everyone I know who crunches numbers for a living.

That's a quote. What more do you want?

The question is not and never has been "Does the GIL have undesirable characteristics?" It has always been "can someone produce an implementation that is missing the GIL and actually better, while meeting all the needs CPython has?" So far, the answer is no, despite rather a lot of smart people trying.

(Also note that many people have succeeded by dropping the second clause. Many non-CPython Python implementations don't have a GIL. But they aren't CPython, which in particular means that extensions written for CPython don't work in them, which is really the key thing that distinguishes CPython from just generic "Python".)

With PyPy the performance will get better, and they also have a GC, so that hinder is removed. I don't really know if PyPy has a GIL, I would guess that they don't.

Running Java threads on a single processor machines makes it not truly multi-threaded then? Python has multi-threading - due to GIL, only one of them execute at a time, which isn't very different from running multiple threads on a single processor machine. It facilitates concurrency, not parallelism.

> claiming that multi-process is the way to do parallel computation across the board is not a sane argument at all.

If you have n processing units, anything greater than n isn't parallel. Spawning 100 threads in a JVM doesn't give you 100 parallel workers(assuming JVM mapped those 100 JVM threads to 100 system threads).

Multi processes make perfect sense for parallel jobs. They do fine with nothing shared and message passing. They are problematic when the jobs need resource sharing.

> having to use proxy servers for database access to minimize connections across all the python process instances

That doesn't sound like pain. Some systems intentionally have kept db connection pooling outside the application server. Application server talks to the manager and manager delegates to the database.

> Using python for anything more serious, like a message queuing system for example is even more prohibitive.

Celery works great. Thank you.

For custom needs, there is gearman, then there is zeromq...and they are not written in Python, and I don't care, and that works for me.

> Meanwhile in the JVM world..

Then why not stick to the JVM world rather than crib and whine in Python world.