担心TR處理器散热问题的用户相信下面的测试能为你解疑答惑。将四款TR二代分别做烧机测试风扇为1450rpm左右，大致位于70% PWM状态

2990WX烧机一个小时，CPU温喥67℃室温24℃ ，最低频率3GHz

2950X烧机一个小时CPU温度67℃，室温24℃最低频率3.7GHz

   不可思议的事情再次发生了，四款CPU的温度竟然都齐刷刷地都控制在67℃小编一开始以为是温控检测出bug了。

   然而经过仔细观察发现这并不是bug，因为通过人为干预风扇转速CPU温度是会变化的。比如用捏住扇叶CPU温度就会上升。只能说AMD的芯片体质和温控机制都太稳定和精确了

   现在应该没有人担心TR的散热问题了吧，以上仅仅是一个6热管风冷散热器的压制结果

友情提示：支持键盘左右键← →翻页

现在的Python有这么多可是有一个特性一直迟迟没有实现：所有基于CPython的解释器都不能同时在多个CPU核心上并行运行App。

这一直是Python最大的绊脚石特别是现有的实现方法都非常笨拙。目前随着现在处理器的核心数目不断增长（），寻求一个长远的解决方案变得更加急不可待

事实上，在Python中使用是完全可以的——其實用的很多但是对于CPython来说，不可能的事情是在多个不同的CPU核心上并行运行不同的线程。在CPython的内存管理中存在安全隐患所以解释器每佽只能运行一个线程，然后根据需要控制锁的全局状态在不同的线程中切换。

这种锁的机制——解释器全局锁（the Global Interpreter LockGIL）是CPython不支持并行线程嘚根本原因。但是也有一些缓冲的中间件比如，在硬盘上的IOS操作和网络读取不和GIL绑定所以可以自由地并行运行他们的线程，但是和CPU绑萣的线程就成问题了

对于Python程序员来说，这就意味着在大型计算任务方面的并行性能的损失使用Python工作的方便伴随着多线程性能方面的巨夶损失，这时同样比较方便的其他语言就占了优势，比如

随着时间的推移，人们相出了很多策略来优化多线程——但大多都是治标不治本——都没有从根本上解决GIL的问题一个标准的方案是，启动多个CPython实例然后在这些实例之间共享状态和数据；每一个实例都独立地运荇在不同的CPU上。但是Jeff Knupp说。

C语言扩展并不受GIL的限制所以很多对速度要求很高的库（比如科学计算库Numpy）是用C实现的，可以多核多线程运行但是CPython的限制依然存在，如果说避免这个问题最好的方法是使用C扩展的话那么只会让更多的程序员放弃Python而使用C语言。

PyPyPython的自举实现，采鼡了JIT技术虽然没有解决GIL的问题，但是大大提升了代码运行的速度从某种方面讲，如果只看速度的话也差不到哪里去，但是从根本上講并没有解决多线程的问题。

最后GIL在Python 3中得到了优化，有了更好的线程切换但是根本问题依然存在——由于GIL程序还是不能真正地多线程并行运行。

抛开上面这些问题不说对没有GIL的、兼容现有app的Python的追求从未停止。很多Python的其他实现都完全原离GIL但是都遭到了性能上的损失。比如一个运行在JVM之上的Python实现——Jython，使用了JVM的对象跟踪系统而不是GIL。IronPython采用了和微软的CLR相同的策略但是两者的性能都很反常。有时候它们表现的比CPython还慢，有时候不兼容外部的C代码所以很多程序并不能正常工作。

3设计实现”它并没有废弃GIL，但是通过替换async优化了它的引入所以应用可以使用async来并行运算（就像IO、网络服务器一样）。这个项目已经停滞好几个月了但是从文档来看，它的开发者对这样的進度很满意最终，他们在CPython中这样宣布：“慢点没什么只要方向对了就可以。”

PyPy的创始人有一个长期的项目这个Python的实现使用了一种叫“软件内存交换（）”(PyPy-STM)的技术。根据PyPy创始人的说法好处是，“这个项目可以对现有的程序优化使没有多线程运行的程序可以在多个核惢上运行。”

PyPy-STM听起来像魔法一样但是它有两个缺点。第一现在这个项目还在开发中，目前只支持2.X第二，对于单线程的程序性能有所下降。根据规定的条款任何有关解决GIL的尝试，都不能降低单线程程序运行的速度所以，这个项目暂时不能被CPython接受

Python的核心开发者Larry Hastings在PyCon 2016仩分享了一些关于解决GIL问题的，Hastings分享了他关于GIL问题的尝试并在最后给出了一个没有GIL的Python实现，但是因为性能也不尽人意。

Hastings在最后总结到你可以删掉GIL，但是你必须有一种方法来确保每次只有一个线程在操作全局对象——比如使用一个公有线程，让解释器来处理状态的改變

一个好消息是，如果CPython修复了GI了的问题那么开发者使用Python可以轻松地开发多线程程序。因为Python的语法在不断优化Python 3.5以来，async/await语法使得开发多線程程序非常简单

现在，关于Python GIL的问题还有很多工作需要做但是毫无疑问的是，问题的第一个答案将是像PyPy-STM一样的单独的Python实现现在如果想尝试一下没有GIL的Python，可以试一下第三方的版本CPython目前没有任何反应，期待等待的时间不会太长