|
|
Python 不能利用多核的问题以后能被解决吗？
关注者
639
被浏览
128,717
24 个回答
Ruby也有GIL，其实GIL并不是性能问题的根源，性能问题的根源是GC。
假设去掉GIL，像Java那样的多核多线程，你会面临更多头疼的OOM问题，以及GC问题，Java的一次Full GC是stop whole world的，你不希望你整个服务器8颗内核一起stop，等待GC完成吧？
所以Java这么多年疯狂投入努力改进VM的GC效率，搞出来各种GC算法，特别是并行GC算法。而且在大内存服务器上，为了提高GC效率，避免过大的内存堆扫描开销，Java现在也强调单机跑多进程呢。
所以你认为Python/Ruby去掉GIL，就解决问题了吗？事实上会引入更多更麻烦的问题。
如果为了提高IO并发性能，用协程就同样可以达到目的，Ruby现在原生支持协程，Lua则是协程方面效率极高的脚本语言，已经证明了这条路。
最后说到多核的问题，Ruby未来发展方向是MVM，即单进程里面跑多个VM，每个CPU内核跑一个VM，每个VM有自己的GC。这个办法其实很不错，既有效利用了进程共享内存，又可以支持多核并行，还解决了全局GC的性能问题。
首先这事就是一个误传，确切说是“python的官方标准实现cpython的版本采用GIL，在逻辑上同一时刻只有一个线程执行”
第一，这不是py的规定，而是cpython的一个实现选择，比如其他实现，jython之类就没GIL的问题
第二，GIL只是规定逻辑上的同一时刻有一个线程执行，但下层多线程还是对应os的线程，并非很多人谣传的py是在vm模拟多线程，而且很多C扩展库都在必要的时候释放GIL以提高线程的并发性，尽管非常有限，但是用来解决阻塞IO并发肯定是没问题
其次，GIL在cpython中被选择，主要根源在于GC方式（参考RednaxelaFX的相关回答），另一个重要原因是简化C扩展库的开发
再次，很多人觉得不能利用多核，效率就低，但事实上就算有去除GIL的版本并且解决了细粒度锁的问题，然后你弄个48核服务器并都占满，很多情况下也只能提升一二十倍速度而已（因为有线程互斥的交互），而这个提升用jit也能达到，如果用C扩展重写核心模块，提速更多，花大力气弄掉GIL根本划不来，何况在不改变GC机制和兼容现有扩展库的前提下，能不能做都是个问题