python - 为什么 GIL 替代品会对性能产生影响？

Question

来自 Java 的 Ruby 和 Python 中的整个全局解释器锁 (GIL) 有点令人吃惊。我已经阅读了一些问题并在 Python documentation 中找到以下摘录:

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.

我没有找到性能影响背后的解释。我试图找出技术原因是什么，但找不到任何好的讨论来确定它。

类似Ruby，在这里我能找到的信息更少。原因是否相同？

Answer 1

简单地说，加锁和解锁多把锁比加锁和解锁单把锁的代价更高。这应该不足为奇，做任何 N 次而不是一次显然需要更多时间(所有其他条件相同)。对于这种事情，规模经济并不真正适用，没有什么大的一次性成本可以分摊所有锁定操作。

编辑:原则上，Java 也有同样的问题，但由于每个人的关注点不同，历史，也许还有其他因素，Java 在细粒度锁方面做得相当好。简而言之，单线程性能并不被认为重要，多线程性能可能比假设的自由线程 CPython 更好。

从历史上看，我不认为曾经有一个带有 GIL 的 JVM(尽管它最初是在单个操作系统线程上运行绿色线程——但这是很久以前的事了)，所以没有历史原因需要保留 GIL 和没有让人厌恶锁的基线单线程性能。取而代之的是，投入了大量的精力让 Java 擅长多线程，并且这种能力得到了广泛的应用。相比之下，即使您解决了单线程 Python 或 Ruby 程序的 GIL 问题而没有性能成本，那里的大多数代码也不会从中受益，而且库……并不糟糕，但与 java.util.concurrent 或者。

因为 Java(现在)有一个显式不提供很多保证的内存模型，所以 Java 程序中的许多常见操作通常不需要任何类型的锁。当然，缺点是 Java 程序员必须在需要时手动添加锁或其他同步。此外，Java 的锁已经看到了很多锁的优化(其中一些是原始研究并首先在 JVM 中引入)——瘦锁、锁省略等——这使得竞争锁非常便宜。

另一个因素可能是 Java 程序几乎完全运行 Java 代码(正如我上面所描述的，如果没有明确请求，则只需要很少的同步)，对运行时库的调用很少。因此，自由线程的 JVM 甚至可以为 JIT、类加载器等提供全局锁(或仅几个粗锁)，而不会对大多数 Java 程序造成太大影响。相比之下，Python 程序将花费大部分时间在 C 代码中，无论是内置模块还是第三方扩展模块。