所以我刚刚在Python全局解释器锁(GIL)http://blip.tv/file/2232410上看完了这个演讲.
它的要点是GIL对于单核系统来说是一个非常好的设计(Python实际上将线程处理/调度留给了操作系统).但是,这可能严重地适应多核系统,最终导致IO密集型线程被CPU密集型线程严重阻塞,上下文切换费用,ctrl-C问题[*]等等.
因此,由于GIL限制我们基本上在一个CPU上执行Python程序,我的想法是为什么不接受这个并简单地在Linux上使用taskset来设置程序与系统上某个核心/ cpu的亲和性(特别是在某种情况下)在多核系统上运行的多个Python应用程序)？
所以最终我的问题是:有没有人尝试在Linux上使用带有Python应用程序的任务集(特别是在Linux系统上运行多个应用程序,以便多个核心可以与一个或两个绑定到特定核心的Python应用程序一起使用),如果是这样的话是结果？值得做吗？是否会使某些工作负载更糟糕？我打算这样做并进行测试(基本上看看程序是否需要花费更多或更少的时间来运行),但我很乐意听取其他人的经验.
另外:David Beazley(在链接视频中发表演讲的人)指出,一些C/C++扩展手动释放GIL锁,如果这些扩展针对多核进行优化(即科学或数字数据分析/等),那么而不是为数字运算获得多核的好处,扩展将被有效地削弱,因为它仅限于单个核心(因此可能显着降低程序速度).另一方面,如果您没有使用此类扩展
我没有使用多处理模块的原因是(在这种情况下)程序的一部分是严重的网络I/O绑定(HTTP请求),所以有一个工作线程池是一个很好的方式从一个盒子挤出性能一个线程触发一个HTTP请求,然后因为它在I/O上等待就放弃了GIL而另一个线程可以做到这一点,所以程序的一部分可以轻松地运行100多个线程而不会伤害CPU太多让我实际使用可用的网络带宽.对于无堆栈的Python/etc,我对重写程序或替换我的Python堆栈并不过分感兴趣(可用性也是一个问题).
[*]只有主线程可以接收信号,所以如果你发送一个ctrl-C,Python解释器基本上试图让主线程运行,这样它就可以处理信号,但因为它不能直接控制运行哪个线程(它留给操作系统)它基本上告诉操作系统继续切换线程,直到它最终命中主线程(如果你不幸,可能需要一段时间).