如CPU的核战争是愈演愈烈，去年HEDT平台全面突破10个核心，今年AMD和Intel更是把服务器上的老本都拿出来摆到桌面平台上了，AMD 32核心的TR 2990WX已经上市，Intel这边28核心也在准备当中。CPU核心数量越加越多，效能也是在宣传中噌噌噌往上涨，但是往往买了这些多核心的土豪们只拿它来扫雷，并没有得到实际体验的提升，那么许多用户可能就会陷入迷茫：这些多核CPU对我来说到底有没有用？
应用软件的分类
对硬件测试者来说，通常测试项目按用途分类，通常就是分为理论计算、游戏、影音视频等生产力工具、内存和磁盘性能等等。对现在的多核心CPU来讲，有些测试软件经常会跑出一些不正常的成绩，导致性能指标没有随着核心数量增加而增长，出现这种情况，就说明该软件无法发挥出CPU应有的效能了。
那么到底什么样的软件能发挥这些多核CPU的全部性能呢？我们不妨换个角度去给这些应用软件分类，借助服务器领域常见的分类方法——计算密集型和IO密集型，实际上这是按照计算机处理信息的工序不同去分类。在讲之前首先说明一下，这里讲的计算密集型和IO密集型，并不完全吻合服务器或工作站对这两种形式的定义，而是以我们自己对CPU资源调度和使用的相对情况而进行的分类。
计算密集型软件，是指需要耗费大量的CPU资源运算，输出的运算结果频率、数据量不大。这样的软件，通常需要耗费大量的CPU资源，而内存、IO则总是处于等待状态，瓶颈在CPU本身。例如3D渲染软件就是一个很典型的例子，在通过建模、计算后，输出一个“结果”：最终渲染完成的图片。CPU会耗费大量的时间在图片本身的计算上，而IO在等待CPU完成后输出结果。
计算密集型软件，CPU资源会被充分利用，如果软件并行度良好，多核心CPU通常会跑在满载的状态。这个时候往往效能会随着核心数量的增加而接近线性增长。
而IO密集型则是反过来，CPU计算单元需要大量和缓存、内存甚至硬盘交换数据，因此CPU核心会等待这些数据传输后才进行处理。我们可以用Prime95中的分布式计算模型来做说明，选择Small FTT时，数据块非常小，通常在8KB以下，CPU只需要和L1缓存交换数据，我们知道L1缓存的速度是非常快的，因此计算效率很高，CPU核心的发热量也会达到最大，这时候属于计算密集型的形式，而选择Blend时，数据块会增大至几百KB甚至几MB的水平，这时候CPU就需要和L2甚至L3缓存、内存交换数据，在IO上花费的时间也就更多，CPU的发热量反而没那么大，计算速度也没有那么快，这就是IO密集型的特点。
再例如游戏，CPU和GPU之间需要频繁通讯，虽然游戏的帧渲染工作全部都是由GPU进行，并进行后端输出，CPU只是负责上层的软件和API的调度处理，计算量不大，与GPU通讯的信息量也不大，因此在GPU性能相同的条件下，CPU-GPU的通讯延迟对游戏帧数的影响成为了第一瓶颈。
在一些生产力工具例如PS、PR的实际应用中，最耗时的两项操作——实时预览和输出，也是需要CPU计算并频繁与内存和硬盘交互的，这些则是属于混合型，计算和IO密集型应用都有。
AMD TR CPU的架构及IO延迟问题
IO密集型应用一定会涉及到两个问题：延迟与带宽。通常多核心CPU的架构设计，决定了IO延迟和带宽都会比核心数较少的CPU大。AMD TR处理器虽然在核心数上一直力压Intel，多Die设计也可以有更好的施展空间，带宽更大已经体现在了内存四通道（EPYC则是八通道全开）和64条PCIE通道上，这里不再多说，例如7-zip，同样是IO密集型软件，TR的表现就非常好。
但是IO延迟问题成了TR处理器不得不考虑的一个影响性能的因素。在16核心的TR 2950X和2920X当中，只有两个Die被启用，两个Die分别连接双通道DDR4内存，以及32条PCIE通道，两个Die中间通过Infinity Fabric（IF）总线连接，启用四个Die的2990WX也是类似的情况，只是每两个Die之间都有IF总线互联。
这样的设计，在IO密集型应用上就不可避免地出现CPU要访问另一个Die的内存和PCIE数据，只要CPU访问非本Die的其他IO设备，就要通过IF总线来传输数据，而IF总线的速度和延迟与内存速度挂钩。按照AMD官方的说法，在内存跑DDR4-3200时，IF总线的带宽达到双向25.6GB/s，内存访问近端Die的通讯延迟是64ns，访问远端Die则是105ns。因此IO密集型应用不得不考虑通讯总线延迟的问题，像2990X这样四个Die都启用的CPU，其中两个Die是不与内存控制器和PCIE控制器相连的，这两个Die和内存、PCIE通讯的延迟可能会比AMD所描述的更大，这也就是2990WX在一些游戏测试中效能很低，开启游戏模式，只启用一个或两个Die之后效能恢复正常的原因。（所以如果以后你们如果看到某篇文章里写到：三百块的G4600玩游戏秒杀32蛋的2990WX也不要大惊小怪……）
操作系统对CPU资源的调度
学过编程的人应该都清楚，操作系统可以调度CPU资源的最小单位是线程，对软件调度CPU资源方面来讲，过少的线程数导致CPU资源无法充分利用，导致有些核心（线程）闲置，过多的线程数则会出现线程上下文切换的开销问题。
线程上下文切换是什么？例如我现在在写文章，发现有不懂的地方，我会停下来去查资料，查完资料后我会继续写文章，从刚才停下的地方继续写。那么开销表现在哪里？当我停下来，去查资料时，我得把word最小化，开启浏览器，去打开谷歌，输入我要查询的资料，查完后，我关闭谷歌，再切回word。这一来一回的切换是需要时间的，除了我需要动脑子写文章和查资料的操作，其他的都是额外的时间开销，这些时间是可以省去的，怎么省呢？我可以在差不多写到这里的时候，让同事帮查资料，他只需要去打开谷歌，查好资料，然后告诉我，当我写到的时候，资料也查好了，这样就不会影响我写文章的速度。对软件调度CPU资源来说，同样是并行计算，如何“完美并行”就是一个很大的学问，过多出现上下文切换开销，同样会增加CPU等待时间，降低软件运行效率。
那么就回到我们最开始的问题。对多核心CPU来讲，第一类无法正常发挥的情况就是软件的线程数少于CPU线程数——并行度不够，例如在TR的测试中，国际象棋只能支持到16个线程，根本没有办法反映CPU的真实性能，哪怕它是计算密集型应用。Windows还傻了吧唧的把前16个线程分配给国际象棋去用，这种毛病从Win7到Win10 1803都没有改过。实际上如果用到16个物理核心，效能可以再提高5-10%。
第二类，IO密集型应用，例如PR视频渲染和PS RAW转JPG，虽然表面上看CPU占用率高，但是CPU需要大量和内存、硬盘交换数据，因此CPU花费许多时间在等待IO数据上，TR 2950X在任务管理器中看似可以满载，实际上CPU并没有被充分利用。当然这些是可以通过软件开发者去做针对性优化以提升性能，比如我们发现Adobe Camera RAW会分配8个线程去处理一张图片，每次只同时处理4张图片，如果针对多核心CPU优化，可让线程分配同时处理更多的图片，并把更多的处理结果储存在内存中，减少IO读取和写入的频率，这样或许速度会提升很多。
第三类，最难以察觉的问题，例如在TR 2950X的评测中，渲染工作Cinebench看似表现很理想，但它也只是支持到256个线程，并且线程越多的时候，渲染工作很快就会跑完，而且线程越多，用于线程调度的开销也就越大。根据我们的测试，TR 2950X在多次运行Cinebench R15时会有3-5%的成绩误差，而在100个以上线程时，几秒钟就跑完了，误差可以达到20%以上。但这类问题在实际的渲染应用中并不存在，因为实际渲染都会要跑至少几个小时的，几秒钟甚至毫秒级别的误差可以忽略，只是一些测试软件没有办法准确反应CPU效能了。
总结：多核心CPU到底适合什么应用？
通过上面的分析，相信大家已经很明白了：多核心CPU对计算密集型的应用会有比较大的性能提升，IO密集型则需要考虑应用对IO延迟的敏感度，多核心CPU更适合吃带宽的IO密集型应用，而不适合对延迟敏感的IO密集型应用，尤其是支持线程数不多的IO密集型应用。
那么再回到我们最开始评测角度对应用软件的分类，看看TR 2950X评测中跑分相对Core i9和Ryzen 7的差距情况必然性：
理论计算：大多是计算密集型，单线程的TR没优势，多线程只要能充分利用的TR有优势，反则也没优势。
游戏：IO密集型，TR的IF总线和内存延迟较大，大多数情况没优势，2990WX更甚，32核全开时部分游戏性能倒退严重或无法运行。少数AI计算量比较大的游戏，可能TR会有一些优势。
生产力工具：看具体软件，渲染类型是计算密集型，TR优势大，例如Cinema 4D、POV-Ray等，2990WX随便把7980XE秒到姥姥家。Adobe软件最新版已经可以支持多核心的CPU了，但实时渲染操作通常是计算和IO密集型混合，TR没优势或优势比较微弱。
对内存敏感的应用：都是IO密集型，但是要看程序对内存带宽和延迟的敏感性。四通道比双通道厉害是肯定的，但是通常实际应用内存带宽需求高的软件比较少，因此7-ZIP、3DMark物理测试这类表现会比较好，但是延迟不及双通道，因此TR SuperPI跑不过IPC相同的2700X，7900X也跑不过8700K这都是很正常的。
因此，TR的测试数据并不是普通小白用户可以轻易琢磨透的，我也不建议大家看天梯图或者“综合性能对比”之类的数据，因为一目无法了然，并且它可能会影响你选购产品的判断。建议大家针对自己对PC的用途，要用到哪些软件，并且针对这些（这类）软件去分析它们的运作模式，进而根据CPU和平台的特性选用合适的CPU。
|
收藏
转播
来自苹果客户端
