不同硬件上构建时间的比较；为什么是非线性结果？

Question

• 为什么不同时代CPU之间的编译时间变化不大，尽管磁盘(NVMe与HDD)和CPU基准在性能上有很大差异？
• 为什么禁用超线程会显著影响Ryzen CPU的性能？

在过去的几个月里，我看到了一些不同的机器，它们都使用CPU运行Linux，这些CPU自发布以来大约有9年的变化，还有一些是最近发布的。较新的CPU从cpubenchmark.net获得了更高的基准数。下面的详细信息包括使用Ubuntu18.04的Linux 4.4.176内核的编译时间。

简单地说，在cpubenchmark.net上得分多倍的CPU肯定不会减少编译次数。事实上，有时也会看到一些微不足道的改进。

改变或修复的瓶颈是什么？Ryzen机器拥有所有最新的硬件设备。或者这是一个综合基准和现实的案例？

这个问题通过编译时比较来讨论基准测试的主题，但没有探讨(缺乏)构建时的可变性。

• 现代Ryzen 2950 X系统
  • 单线程评级: 2208
  • 磁盘: NVMe
  • 资料来源: Linux内核，4.4.176，用Ubuntu的.config编译。
  • 调用:使-j32
  • 编译时间: 25997u 4910 s 17:25壁时

• 相同的系统，超线程(或任何AMD称呼它)关闭。
  • 资料来源: Linux内核4.4.176，相同的.config文件。
  • 调用:使-j16
  • 编译时间: 10561u 1796s 13:44

这意味着编译时间减少了20%以上，从17:25减少到13:44，相差3分41秒。只需禁用超线程功能。

新数据，2019-03-08

编译时间实际上是单调的，但不是线性的，直到make -j12，用了12:46和十几个进程。然后，编译时间缓慢而单调地增加到make -j24的最后一次运行。在这些测试中，超线程被关闭了。

不管瓶颈是什么，都要经过12个并行线程。

新数据- 2019-03-27

在调优X.M.P.内存配置文件(但仍然使用单通道访问)之后，时间减少，直到16个线程的最小值达到10:08.5；线程数量与内核相同(未启用HT )。除了一个例外，编译时间在32个线程时缓慢地增加到10:41。

启用双通道内存后，17个线程的次数减少到6:47.5。在此之后，时间在20个线程上来回摆动，至少为6:46.6。这可能是偶然的，很可能不是达到最低限度点的最后一点。在这种情况下，最多只测试了24个线程。

内存似乎是一个巨大的因素，也是这个处理器的瓶颈。在优化配置内存后，在问题上抛出更多的处理线程似乎没有多大帮助或阻碍。

结论

• 内存是此CPU的一个主要潜在瓶颈，必须对其进行适当配置以利用处理器。
• 像处理器一样多线程的旧规则。
• 在第一次测试之后，没有对超线程进行测试，因此无法得出这方面的结论，除了使用单通道内存的默认配置可能会使超线程内核缺乏内存访问。

Answer 1

也许，这更多的是硬件问题，而不是软件工程问题。

现代BIOS中有一个名为X.M.P的内存设置，默认情况下，这个设置是主板支持的内存的最低公分母。要充分利用已安装的内存，必须进入BIOS并设置X.M.P.Profile。在这种情况下，除了默认设置之外，似乎只有一个配置文件可用。

另一个问题是设置双通道内存访问与单通道内存访问。这将需要使用手册来确定如何安装内存以启用此设置。

使用不同软件进行的测试构建比以前的默认设置节省了20%以上的构建时间。因此，我们有希望在未来取得更好的表现。

调好后，我将报告最后的数字，以供比较。

2019-03-27结论

内存是这个CPU的主要瓶颈。有关更多细节和结论，请参见问题。

这个问题没有引起太多的兴趣，所以这可能是最后一个条目，除非有人专门问了一个问题。

Answer 2

就在我头顶上：

1. CPU性能并不是影响编译时间的唯一因素。
2. 基准并不总是考虑到影响实际程序的性能因素。
3. 缓存亲和力可能是比CPU速度更大的因素。
4. 编译器并不总是有效地利用并发机制。
5. 一般来说，像编译器这样的程序的编写方式可以利用(或无法利用)特定的CPU特性。
6. 并发机制有开销。如果软件没有从提供的并发性中获得任何好处，则结果是净负数。

总之，这很复杂。像编译这样的高度复杂的任务并不总是通过基准很好地建模。您必须考虑其他影响整体性能的现实因素，如在硬盘上查找时间和编写代码的方式。

有关这方面的一个简单但相当引人注目的示例，请参见这里。

Answer 3

编译大型项目可能需要读取数百个源文件，并编写数百个中间(对象)文件。然后再读取所有这些中间文件以编译已完成的可执行文件或库。

通常，最大的瓶颈不是CPU，而是磁盘子系统(磁盘驱动器本身和磁盘控制器)。

多核或超线程CPU可以通过向磁盘子系统发送多个同时读或写请求来进一步混淆系统，每个请求都要求不同的文件。如果磁盘具有较高的查找时间，那么与单个核心CPU相比，这甚至会降低性能。

当文件位于远程服务器上并映射为本地计算机上的驱动器时，磁盘性能的影响可能特别严重。