AMD Rome第二代EPYC评测：SPEC CPU2006评估

虽然SPEC2006可能已经被SPEC2017所取代，但我们已经积累了大量关于SPEC2006的经验。考虑到我们在数据中心基础架构方面遇到的问题，这是我们进行原始性能分析的第一轮最佳选择。

单线程性能仍然非常重要，尤其是在维护和设置情况下。在很多情况下，可能是运行一个大型bash脚本，尝试一个非常复杂的SQL查询，或者配置新的软件，而用户根本没有使用所有的内核。

尽管SPEC CPU2006更面向高性能计算和工作站，但它包含各种各样的整数工作负载。我们坚信，我们应该尝试模仿性能关键软件是如何编译的，而不是试图获得最高分。为此，我们:

使用64位gcc:目前linux上最常用的编译器，用于整数工作负载，很好的全面编译器，它不会试图“打破”基准测试(libquantum…)，也不会仅支持特定的体系结构；
使用4和8.3版本:带有Ubuntu 18.04 LTS和19.04的标准编译器；
使用-Ofast -fno-strict-aliasing优化:在性能和保持简单之间取得良好的平衡；
在可移植性设置中添加“-std=gnu89”，以解决某些测试无法编译的问题。

最终目标是在非主动优化的应用程序中度量性能，在这些应用程序中，通常由于某些原因，一个多线程不友好的任务会让我们等待。缺点是仍然有相当多的情况下gcc会生成次优的代码，这与ICC或AOCC的结果相比会引起很大的轰动，它们经过优化以在SPEC代码中寻找特定的优化。

首先是单线程结果。值得注意的是，由于采用了turbo技术，所有处理器的时钟速度都将高于基准时钟速度。

遗憾的是，我们不能及时测试英特尔Xeon 8280的数据。然而，Intel Xeon 8280将提供非常相似的结果，主要的区别是它运行的时钟速度提高5% (4 GHz vs 3.8 GHz)。所以我们期望其结果会比Xeon 8176高3-5%。

根据特殊规范许可规则，由于这些结果尚未正式提交给特殊规范数据库，我们必须声明其为评估结果。

SPEC CPU的分析总是复杂的，它混合了编译器生成的代码类型和CPU架构。

首先，最有趣的数据点是gcc 8生成的代码对于EPYC处理器来说似乎有了很大的改进。我们重复了三次单线程测试，结果都是一致的。

hmmer是分支密集型基准测试之一，也是分支预测影响较大的另外两个工作负载(分支未命中的百分比略高)gobmk，sjeng使用新的TAGE预测器，在第二代EPYC上表现更好。

为什么IPC低omnetpp(“网络sim”)没有显示出任何改进对我们来说是个谜，我们期望更大的L3缓存会有所帮助。然而，这是一个非常喜欢大型缓存的测试，因此英特尔Xeon处理器非常具有优势(38.5 – 55 MB L3)。

视频编码基准”h264ref“在某种程度上也依赖于L3缓存，但该基准更依赖于动态随机存取存储器带宽。很明显EPYC 7002具有更高的动态随机存取存储器带宽。

指针跟踪基准（XML处理和路径查找）在前一代EPYC(与Xeons相比)上表现不佳，但在EPYC 7002上表现出非常显著的改进。

多核SPEC CPU2006

为了记录在案，我们认为规格中央处理器“速率”指标对估计服务器中央处理器性能没有太大价值。大多数应用程序不会并行运行许多完全独立的进程；线程之间至少有一些交互。

我们需要再强调一遍：SPECint率测试可能不现实。如果启动112到256个实例，会造成巨大的带宽瓶颈，无法进行同步，并且100%的一致CPU负载，所有这些在大多数整数应用中都是非常不现实的。

具体的速率估计结果强调了新EPYC处理器的所有优势：更多内核、更高带宽。当时，它忽略了一个较小的缺点:较高的内部延迟。所以这是EPYC处理器的理想情况。

然而，即使我们考虑到AMD拥有45%的内存带宽优势，而英特尔最新芯片(8280)提供了大约7%到8%的性能，这也是非常惊人的。平均而言，EPYC 7742的SPECint率是现有最佳嵌入式英特尔Xeon处理器的两倍。

有趣的是，我们看到大多数利率基准运行在P1时钟或最高p-1状态。例如，这是我们在运行libquantum时看到的结果：

而h264ref等一些基准测试则以较低的时钟运行。

当前的服务器不允许我们进行精确的功率测量，但是如果AMD EPYC 7742能够在3.2千兆赫的所有内核上运行整数工作负载时保持在225瓦的工作负载范围内，那将是非常令人惊讶的。长话短说:新款EPYC 7742似乎能够在所有内核上运行整数工作负载的同时，支持比同类英特尔型号更高的时钟。