Python 不能利用多核的问题以后能被解决吗？

首先，语言应该在什么级别支持多线程。C 通过操作系统的 preemptive scheduler 支持多线程，同时提供 critical section, wait/notify 这样的同步机制。问题在于，这样的同步机制太低级，在实际应用中经常需要封装为高级的同步机制，比如多线程的生产者－消费者队列。高级动态语言的设计者面临三个选择：

1. 在语言中直接提供类似 C 的机制（Java）；
2. 设计良好的 C 接口，在同一进程中运行多个虚拟机，利用 C 把低级同步机制封装成多虚拟机之间的高级同步机制（Lua），或者把多线程优化完全封装在一个 API 之内（比如 Intel MKL 的各种多核算法）。
3. 多进程。

方法 1 是得不偿失的。因为低级同步机制的优势在于效率，而考虑效率就必须考虑诸如 L1/L2/L3 cache 实效之类的底层情况。这对于解释执行的语言（即使有 JIT）来说是无法控制的。所以高级动态语言提供底层同步机制实际没有必要。应该多走方法 2 和 3。其中又以 2 最为灵活。

移除 GIL 难吗？不难，因为根本没有必要移除。如果 Python 能在一个进程中初始化多个 VM，同时其标准库在 C 级别做出足够多的常用多核优化就没有问题。Python 其实是希望实现另一个功能，异步操作。尽管异步操作和并行计算都可以通过多线程来完成，但是其实前者更加适合用协程或者用户级线程来完成。但是 Python 是 stackful 实现，也就是 byte code 借用 C runtime stack 来维护自己的运行状态。这种机制的弱点就是不容易用跨平台的方式来实现协程，所以利用 OS 多线程加 GIL 也就成了模拟协程语意的妥协手段。

补充一下。C 的线程和线程同步机制虽然底层，但是只有这种机制才能覆盖所有 use case。而其它的高层抽象只能适合某种 case。所以，当我说高级动态语言需要高级的线程操作时，我的隐含意思是这种语言同时还要有和 C 进行良好的互操作来随时扩展这种抽象。

　　　　　　　　　　　　　 查看评论 回复