2、其次首先打开m1macpython，点击主界面。
3、最后在主菜单点击调用多核即可。
比方我有一个4核的CPU，那么这样一来，在单位时间内每个核只能跑一个线程，然后时间片轮转切换。但是Python不一样，它不管你有几个核，单位时间多个核只能跑一个线程，然后时间片轮转。看起来很不可思议？但是这就是GIL搞的鬼。任何Python线程执行前，必须先获得GIL锁，然后，每执行100条字节码，解释器就自动释放GIL锁，让别的线程有机会执行。这个GIL全局锁实际上把所有线程的执行代码都给上了锁，所以，多线程在Python中只能交替执行，即使100个线程跑在100核CPU上，也只能用到1个核。通常我们用的解释器是官方实现的CPython，要真正利用多核，除非重写一个不带GIL的解释器。首先，语言应该在什么级别支持多线程。C 通过操作系统的 preemptive scheduler 支持多线程，同时提供 critical section, wait/notify 这样的同步机制。问题在于，这样的同步机制太低级，在实际应用中经常需要封装为高级的同步机制，比如多线程的生产者－消费者队列。高级动态语言的设计者面临三个选择：在语言中直接提供类似 C 的机制（Java）；
设计良好的 C 接口，在同一进程中运行多个虚拟机，利用 C 把低级同步机制封装成多虚拟机之间的高级同步机制（Lua），或者把多线程优化完全封装在一个 API 之内（比如 Intel MKL 的各种多核算法）。
多进程。
方法 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 进行良好的互操作来随时扩展这种抽象。
