如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。
|