title: Why do GIL alternatives have an impact on performance?
body: <p>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 <a href="http://docs.python.org/2/faq/library#can-t-we-get-rid-of-the-global-interpreter-lock" rel="nofollow">Python documentation</a> the following excerpt:</p>
  
  <blockquote>
    <p><strong>Can’t we get rid of the Global Interpreter Lock?</strong> </p>
    
    <blockquote>
      <p>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.</p>
      
      <p>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) <strong>this ran ordinary Python
      code about twice as slow as the interpreter using the GIL</strong>. On Linux
      the performance loss was even worse because pthread locks aren’t as
      efficient.</p>
    </blockquote>
  </blockquote>
  
  <p>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.</p>
  
  <p>Similar in Ruby, here I could find even less information. Are the reasons the same?</p>