Wednesday, 21 August 2013

Why do GIL alternatives have an impact on performance?

Why do GIL alternatives have an impact on performance?

Coming from Java the whole Global Interpreter Lock (GIL) in Ruby and
Python is kind of startling. I have read a bit into the problem and found
in the Python documentation the following excerpt:
Can't we get rid of the Global Interpreter Lock?
The global interpreter lock (GIL) is often seen as a hindrance to Python's
deployment on high-end multiprocessor server machines, because a
multi-threaded Python program effectively only uses one CPU, due to the
insistence that (almost) all Python code can only run while the GIL is
held.
Back in the days of Python 1.5, Greg Stein actually implemented a
comprehensive patch set (the "free threading" patches) that removed the
GIL and replaced it with fine-grained locking. Unfortunately, even on
Windows (where locks are very efficient) this ran ordinary Python code
about twice as slow as the interpreter using the GIL. On Linux the
performance loss was even worse because pthread locks aren't as efficient.
What I did not found is the explanation behind the performance impact. I
have tried to find out what the technical reasons are, but could not find
any good discussion that nails it down.
Similar in Ruby, here I could find even less information. Are the reasons
the same?

No comments:

Post a Comment