有人知道 Python 3.1 中 Global Interpreter Lock 对 C++ 多线程集成的命运吗
问问题
13267 次
7 回答
25
GIL 在 CPython 3.1 中仍然存在；Unladen Swallow项目旨在（在许多其他性能提升中）最终将其删除，但它仍然是其目标的一种方式，并且首先在 2.6 上工作，目的是最终移植到 3.x，无论 x 将由2.y 版本被认为完成的时间。目前，多处理（而不是线程）仍然是在 CPython 中使用多核的选择方式（IronPython 和 Jython 也很好，但它们目前不支持 Python 3，也没有使 C++ 集成变得那么容易；- ）。
于 2009-08-03T15:25:03.777 回答
17
Python 3.2 的 GIL 将发生重大变化。查看Python 3.2 的新增功能，以及在邮件列表中启动它的线程。
虽然这些变化并不意味着 GIL 的终结，但它们预示着潜在的巨大性能提升。
更新
- Antoine Pitrou 在 3.2 中使用新 GIL 的总体性能提升可以忽略不计，而是专注于改善在某些极端情况下出现的争用问题。
- David Beazley 做出了令人钦佩的努力来实现调度程序，以在 CPU 和 IO 绑定线程混合时显着提高性能，但不幸的是被击落了。
- Unladen Swallow 工作被提议在 Python 3.3 中合并，但由于该项目缺乏结果而被撤回。PyPy现在是首选项目，目前正在申请资金以增加对 Python3k 的支持。目前，PyPy 成为默认值的可能性很小。
在过去的 15 年中，人们一直在努力从 CPython 中删除 GIL，但在可预见的未来，它会一直存在。
于 2010-01-26T04:51:43.343 回答
9
GIL 不会影响不使用 python 对象的代码。在 Numpy 中，我们为计算代码（线性代数调用等）发布了 GIL，底层代码可以自由使用多线程（实际上，那些通常是对 python 一无所知的 3rd 方库）
于 2009-08-04T01:17:51.500 回答
4
GIL 是个好东西。
只需让您的 C++ 应用程序在执行多线程工作时释放 GIL。Python 代码将继续在未受破坏的其他线程中运行。仅当您必须触摸 python 对象时才获取 GIL。
于 2009-08-03T20:39:39.280 回答
1
如果 GIL 碍事，只需使用多处理模块。它产生新的进程，但使用线程模型和（大部分）api。换句话说，您可以以类似线程的方式进行基于进程的并行性。
于 2011-02-11T04:05:27.563 回答
1
我想总会有一个 GIL。原因是性能。使所有低级访问线程安全 - 意味着在每个哈希操作等周围放置一个互斥锁是很重的。请记住一个简单的语句，例如
self.foo(self.bar, 3, val)
目前可能已经有至少 3 个（如果 val 是全局）哈希表查找，如果方法缓存不热（取决于类的继承深度），可能会更多
它很昂贵——这就是为什么 Java 放弃了这个想法并引入了不使用监视器调用的哈希表来摆脱其“Java 很慢”的商标。
于 2009-09-21T21:36:43.193 回答
1
据我了解，“brainfuck”调度程序将从 python 3.2 替换 GIL
于 2011-02-11T03:54:50.567 回答