回看联想小新 Pro 13 2019 锐龙版

创作立场声明：天猫自购自用的实际用户，无任何直接间接利益相关。

这是一篇完全迟到并且没有任何产品图的评测，对象是小新 Pro 13 2019 锐龙版，当时我是用 4499 在某猫官方旗舰店购买的，应该属于第二波吧。

购买缘由

我平时其实并不怎么需要移动办公，购买的冲动完全是因为这款产品在当时的确是有很多重要的特性能适应我的一些工作需求，例如标称 100% sRGB 色域的 2k 屏幕、方便的 PD 充电、过得去的性能，以及相当不错的价格。

买回来以后主要都是用作外勤，因为平时的机器是一台很老的台式机（2600K + 24GB 内存），而我日常的应用也就是上网、处理照片、写写文章之类的，台机会比较好使（我给它配了块对有些人来说不是很般配的 RTX 2070 FE）。

使用感受

还是说回这台小新 Pro 13 2019 锐龙版吧。在我的外勤中，都是用作现场活动照片直播的后期处理上，用到的软件就是 Lightroom 或者 Capture One，以我的观察，性能方面是可以满足 24M 像素的 JPG 现场图片直播处理的。

最大的问题倒是它的屏幕并没有达到 100% sRGB，使用 i1 Display Pro 实测，色域只有 89%，这是让人有点失望的，因为现场图片处理，很多时候都是需要肉眼判断饱和度的，11% 的色域覆盖差别是足以产生肉眼可见的区别。

虽然我将这台笔记本视作我的业务机，但是作为一个喜欢倒腾的人来说，在日常有台机使用的情况下，对这台笔电作更一步的研究是很正常的事情。

首先是软件方面。

我拿到笔记本后不久就重新倒了操作系统，Windows 10 在安装完成后，进行初始化设置的时候提示用户设定人像识别，进入系统后，可以发现操作系统已经自动激活，即使我安装的时候选择的是 Windows 10 专业工作站版也都被激活了。

完成 Windows 10 安装后，唯一需要做的驱动安装其实只有 AMD 显卡驱动更新，驱动安装后需要重启。

最后就是需要安装联想 Lenovo Utility 工具，只有安装了这个工具后，才能执行诸如 Fn+Q 切换功率限制等键盘映射操作。

小新 Pro 13 2019 锐龙版的触控板在 Windows 下很容易出现轻触边点击的情况，容易引起误操作，这个问题可以到 Windows 10 设置里的触控板相关设定关闭掉即可。

如果是 Ubuntu 20.04 的话，基本上也是能正常使用，就是启动进入桌面后，需要手动在一秒时间内把鼠标箭头推到屏幕右下角，不然屏幕上会有一个动不了的鼠标箭头初始化“遗址”残留在屏幕上。

在 Ubuntu 下查看 Ryzen 3550H 的 p-state，使用 Zenstates 虽然能更改 FID 设置、禁用 P1、P2，但实际上并不起效，实时监控里依然是原来的变频状况

在 Ubuntu 下查看 Ryzen 3550H 的 p-state，可以看到频率 ID 是 21 倍，但是这并不反映处理器实际的可切换最高频率。小新 Pro 13 锐龙版在 Ubuntu 里透过 Zenstates 修改 FID 更改倍频并不实际起效。

功率限制模式设置调整（Fn+Q）目前只能在 Windows 中安装 Lenovo Utility 后才能有效实现，一旦设置某个模式后，即使重启后，该模式也依然生效（即使是重启至 Ubuntu 里），换而言之，这个功能的内部实现虽然和操作系统无关的，但是目前只有 Windows 版下可以进行设置。

Fn+Q 组合键可以设置的三种模式分别是：性能（联想宣传资料中称之为野兽模式）、平衡、节电，分别是 35 瓦、15 瓦、12 瓦，我们可以透过安装 AMD uProf 来查看当前的功率约束状态：

在 AMD uProf 中查看到的小新 Pro 13 锐龙版 2019 三种功率约束模式

在野兽模式下，小新 Pro 13 2019 锐龙版可以做到全核 3.7GHz 满载运行，但是前提是不要触及 AMD 官方公布的 115 摄氏度温度墙，但是在实际使用中，我发现小新 Pro 13 2019 锐龙版在全核 3.7GHz 下，持续运行大约 20 秒左右的话就比较容易触及 100 摄氏度，此时虽然未达到 115 摄氏度，但是频率依然会降低到全核 3.5GHz 左右。

使用监控工具来查看的话，在全核 3.7GHz 的情况下，CPU 全片功率大约是 23.5 瓦，比 35 瓦的约束低大约 32%，这说明降频完全是因为温度墙的问题，小新 Pro 13 2019 锐龙版在触及温度墙的时候虽然风扇转速明显提高，键盘也比较热，但是风扇转速并未达到全速运行。

根据观察，小新 Pro 13 2019 锐龙版只有在刷 BIOS 的时候风扇才会达到全速运行，风扇全速运行的声音可以称之为啸叫，据我所知，还没有什么什么软件可以对这台笔电的风扇转速包线进行手动设置。

小新 Pro 13 2019 锐龙版处理器和显卡信息

Capture One 20 RAW 导出 JPG 性能测试

由于这台笔电主要是作为外勤图片处理使用的，因此我在 Capture One 20 中做了一个导出测试，测试对象是 50 张 5D Mark III .cr2 文件，以原分辨率、300dpi、sRGB 模式导出为 .jpg 文件，分别使用纯 CPU 和加上 GPU 加速来测试：

纯 CPU 导出

启用核显 GPU 加速

测试结果还是比较有意思的。

大家可以看到，如果使用纯 CPU 来做导出的话，耗时需要 205 秒（速度和我台式机 2600K 纯 CPU 导出相当），处理器温度最高达到 103 摄氏度。

而在启用了看似鸡肋的核显 GPU 加速后，耗时是 158 秒，相当于每 3.2 秒处理一张 raw 到 jpg 的导出，相对于纯 CPU 处理提升了 23%，而处理器最高温度只有 78 摄氏度，提速降温作用非常明显。

不过 Ryzen 3550H 的核显速度还是比较弱鸡的，如果厂商可以提供独显版的话，性能应该会更快。例如我的 2600K 配合 RTX 2070，做同样的处理，时间只需要 56 秒，相当于 1.1 秒处理一张。当然，小新 Pro 13 2019 锐龙也就是一台轻薄本，这是可以理解的（我就是想要独显版而已 ）。

SPEC CPU2006 1.2 处理器测试套件

既然安装了 Ubuntu，不妨跑一些 Linux 的测试，我选择的是 SPEC CPU2006 1.2，它是 spec.org 提供的处理器子系统性能测试套件，是所有处理器、编译器、系统集成、跨国电脑厂家都必定测试的性能分析工具，按照整数和浮点可以分为 CINT 2006 和 CFP2006 两部分，以源代码的方式提供，测试包大小大概是 2.6 GiB。

SPEC CPU 2006 包含两个大的测试组，分别是针对整数计算 CINT2006 和浮点计算的 CFP2006。其中 CINT 2006 有 12 个 子项目，其中 9 个使用 C 语言，3 个是 C++ 语言；CFP2006 包含有 17 个子项目，4 个是 C++、3 个是 C、6 个是 Fortran，还有 4 个混合使用了 C 和 Fortran

CPU2006 是 SPEC 在 2006 年推出的测试包，距今有 14 年了，在 CPU2017 发布后不久，CPU2006 已经被列为退役状态，但是得益于英特尔的牙膏速度在过去 10 年都挤得很慢，所有子项目依然需要大量的时间才能完成，这使得测试结果非常稳定，所以 CPU2006 其实还是很适合用于对比现有处理器性能的。

此外，目前好像没有看到过谁在笔电上跑 CPU2006，强大好奇心必须得到满足。 至于 SPEC CPU2017，我已经全部跑通了，但是小新 Pro 13 2019 锐龙版内存有点太勉强，因为 CPU2017 里的 657.xz_s 要吃 14.5 GiB 内存，跑这个子项目的时候小新 Pro 13 爆内存了（难道要试试看在 TinyCore Linux 里跑？） 。

使用 CPU2006 的最大难点是需要测试人员自己选定能让测试跑通的兼容选项，因为不同的操作系统、编译器都和 CPU2006 存在不同的兼容性和限制问题，这需要花费测试人员大量的时间来调整。

除此以外，按照 SPEC 的规定，要求测试只有在 --reportable（要求分别运行 test、train、reference 三种工作集，其中 reference 工作集需要跑三遍，然后取 reference 三次测试数据中的中值作为测试结果）以及测试人员提供编译器开关说明（一个可能需要自己修改的 .xml）文件的情况下，测试结果才会被判定有效。当然，具体的规则还是相当多的，大家可以参考这里：，我的测试都是完全遵循相关规定来跑的，所以测试结果文件不会出现 invaild（无效）的标记。

完整的 CPU2006 测试分为速度（speed）和速率（rate）两种模式，这两个模式下根据编译器优化程度又分为 base 和 peak。在 base 或者说基线模式下，所有测试只允许相同的优化开关，而 peak 或者说峰值，就允许针对不同的子测试设定针对性的编译器开关。

一般来说，在比较处理器的时候，base（速度模式下的测试结果就是 SPECint_base2006 和 SPECfp_base2006）的测试结果会更有普遍价值，而且在 SPEC CPU2006 的测试规则中也允许只跑 base。

CPU2006 的测试结果是将在一台参考机器（Sun Ultra Enterprise 2 工作站，处理器是 97 年的 296-MHz UltraSPARC II）上跑的时间除以当前测试机器的耗时，得出各个子项目的倍率，然后将这些倍率结果进行几何平均，得出的数字就是 CPU2006 在该模式的下结果，例如某台机器的 SPECint_base2006 为 20 的话，意味着该机器的单线程整数性能是参考机器的 20 倍。

我在这里使用 Ubuntu 20.04 和该发行版软件里最新的 gcc 10.0.1 来测试 SPECint_base2006 和 SPECfp_base2006，编译的优化参数很简单，只用了以下四个开关：

-march=znver2（Rayzen 3550H） / -march=sandybridge（Core i7 2600k）
-m64
-Ofast
-fno-strict-aliasing

此外还有针对不同测试子项目的兼容性设置，这里就不一一叙述了，大家有机会的话自己试吧（兼容性或者说 portbility 设置 SPEC 的规定，必须是获得 SPEC 认可，需要和性能无关，只能用于确保运行结果正确）。

这里用的 -march=znver2 原本是针对 Zen 2 微架构，但是根据我 dump 下来的汇编码，发现 gcc 使用 -march=native 或者直接指定 znver1 编出来的代码是没有 AVX、AVX2，需要使用 znver2 才能看到代码中有使用 ymm 寄存器（AVX/AVX2 的寄存器都叫 ymm）：

将编译后的代码反汇编得到的汇编文件，表明使用 -march=znver2 后，程序中启用了 fma 指令和 AVX/AVX2 等指令扩展

测试比较对象分别是小新 Pro 13 2019 锐龙版以及我的旧台式机（Core i7 2600K 锁定 3.8GHz，DDR3-1600 双通道 24GB），均关闭了超线程，主要目的是测试新老处理器的单核单线程性能，所以两个处理器的测试数据分别只有两组，分别是 SPECint_base2006 和 SPECfp_base2006。

SPEC CPU2006 采用命令行方式执行，在测试之前我们先关闭 Ryzen 3550H 的超线程，确保测试可以使用各个内核的所有资源

至于 CPU2006 rate 或者说多核性能就免了，Ryzhen 3550H 跑 8 小时的四核满载必定会有频率缩缸的情况，而我是比较倾向于看看单线程时候的速度，这时候的结果更适合于比较内核级的微架构性能。

SPECint_base2006 Ryzen 3550H / Core i7 2600K 测试结果

SPECfp_base2006 Ryzen 3550H / Core i7 2600K 测试结果

根据我的观察，在关闭超线程的情况下，Ryzen 3550H 运行测试的内核基本上都可以保持 3.7GHz 全速模式，对它不利的因素基本上就是核显共享内存了，这需要占用一定的内存和总线带宽。

相较之下，我的 2600K 是运行于 3.8GHz 关闭超线程，频率大约快了 2.7%。由于使用独立显卡，内存方面是没有额外占用方面的影响。

内存规格方面，虽然前者是 DDR4-2400 双通道（38.4 GiB/s），后者是 DDR3-1600（25.6GB/s），但是后者的时延一般更快，而我们的测试是偏时延而非吞吐，所以两者在这点上是各有所长。

SPECint_base2006 的 2600K 3.8GHz 得分比 Ryzen 3550h 3.7GHz 快大约 6%，在具体的子项目 471.omnetpp（校园网仿真） 和 483.xlancbmk（xml 文件处理）中，领先幅度达到 30% 的级别，而 Ryzen 3550H 3.7GHz 在 456.hmmer 中取得了 30% 的领先。

根据处理器内建的硬件事件计数器数据，在 456.hmmer 这个测试中，Zen+ 的前端（Front-End，处理器流水线中的取指、动态分支预测、解码等工位）停滞指令数是平均 0.6%，后端（Back-End，处理器流水线中的执行、写回、访存等工位）停滞指令数是平均 52.4%，而 Sandybridge 分别是 25.2% 和 6.8%，Sandybridge 受前端瓶颈的影响较大。

一般来说，当后端出现较高停滞或者说停摆的原因可能是因为一些需要跑的指令时延较高，例如除法、开方以及内存操作等；而前端出现较高停滞的结果是无法提供充足的微操作给后端跑，原因可能是指令缓存命中缺失、复杂指令未被解码至微操作缓存（uop cache/queue 或者说 L0 Cache、DSB）。

Zen+（Ryzen 3550H 的微架构）拥有 64-KiB 一级指令缓存，2048 条微操作缓存（L0 Cache），分别是 Sandybridge 的两倍和 1.33 倍。

此外，从 456.hmmer 的动态分支预测失误统计来看，Zen+（456.hmmer 需要跑两个命令，预测失误率分别是分别是 0.58% 和 1.07%）也不逊色于 SNB（0.8% 和 1.00%）。

所以 SNB 在这个测试中的瓶颈比较大的可能是在指令缓存上。相较之下，而 Ryzen 3550H 的瓶颈就是后端效率上，前端的资源相对比较充沛。

事实上，在 CPU2006 的各个单独测试中，456.hammer 的数据集并不大（两个工作集运行时候的内存占用分别是 26MB 和 5MB），但是会有大量的内存操作，load（载入）指令的占比极高（50~60% 左右，取决于编译器）。

CFP2006 中的 470.lbm 需要访问的数据集超过 400MiB，Ryzen 3550H 的 L3 高速缓存是 4MiB，而 Core i7 2600K 是 8MiB，这使得前者的高速缓存命中缺失率要比后者更高。

根据硬件计数器的记录，Ryzen 3550H 的前端单元停滞周期是 0.37%，后端单元停滞周期是 91.21%。相较之下，Core i7 2600K 分别是 66.51% 和 24.41%，Ryzen 3550H 在这个测试中明显受制于 L3 高速缓存的大小约束。这样的结果导致了 Ryzen 3550H 在这个浮点子测试的 IPC 是 0.84，而 Core i7 2600K 可以达到 1.32。

需要注意的是，我这里使用的编译器开关并不完全一样（一个是 znver2，另一个是 sandybridge），所以测试结果反映的是在当前新版编译器下接近日常编译方式的最佳化性能，所以这里的测试结果或者说类似方式的测试结果相对简单，在没有进行全面的 profiling 情况下，测试结果并不能严格反映微架构上的细微区别，并且各个子测试的代码和负载压力类型对微架构的压力各不相同，但是至少最低限度上看出谁在同样的宏观任务上谁的内核可以跑的更快。

总结

总括而言，小新 Pro 13 2019 锐龙版的性能大致和我现在的 Core I7 2600K 性能非常接近，整数性能这边略慢一点，但是浮点有比较明显的优势，瓶颈主要在 L3 Cache 大小，64KiB L1 指令高速缓存和 2048 条微操作高速缓存让 Ryzen 3550H 在许多应用提供了比 Core I7 2600K 更高的 IPC，带着小新 Pro 13 2019 锐龙版出外勤对我来说，只要找到插电，其性能表现就和我带着一台 Core I7 2600K 的台式机相当，可以应对大多数高负荷外勤场合。

文章里我提供的 Ryzen 3550H 和 Core I7 2600K CPU2006 测试结果还是挺有意思的，可以说是一场我非常期待的时隔十年的新旧对话，一台 4000 元价位的笔电，CPU 性能和 10 年前的*级台式机处理器相当，看上去似乎是有点让人失望，但是让人高兴的是，今年基于 Zen2 的笔电目前来看在 IPC 和综合性能上都有极高的提升，明年的 Zen3 笔电又将会有怎样的发展呢？这实在让我充满期待。