为什么服务器 CPU 执行的任务比具有相同基准分数的 Macbook Pro CPU 更快?

dan*_*dan 12 mac cpu intel-core-i5 benchmarking

鉴于以下 CPU 和 GeekBench 分数:

  • Amazon EC2 z1d.large 实例:Intel Xeon Platinum 8151 4061 MHz(1 核)单核得分:1094,多核得分:1300

  • Macbook Pro 笔记本电脑:英特尔酷睿 i5-8259U 2300 MHz(4 核)单核得分:1002,多核得分:4104

Xeon 在单线程基准测试中的速度提高了 9.1%。

但是,当我在两台设备上编译 javascript 应用程序代码(单线程)时,至强完成任务的速度提高了 60%。为什么?基准分数表明至强仅快 9%。

他们都有 NVME 驱动器,所以这不应该是瓶颈。我认为也不会有 Mac 与 Linux 操作系统的问题,因为 Mac 是基于 linux 的。

这是因为至强是服务器/台式机 CPU 吗?并以 100% 的速度和功率运行,而 Macbook Pro CPU 没有以全功率运行,必须等待 Intel Turbo Boost 加速?

Mok*_*bai 50

基准是一些非常具体的性能特征(峰值指令率)的模糊手波,通常不考虑系统中的其他因素。

可以对程序产生重大影响但不会达到峰值指令率的非详尽清单:

  • 记忆。类型、带宽、通道。这些都会对数据到达 CPU 以使其工作的速度产生影响。与台式机或笔记本电脑 CPU 相比,服务器通常具有更多的 RAM 通道、更高的数量和更高的峰值带宽。如果您无法以足够快的速度将数据传送到 CPU 以达到该速度,那么拥有高单核指令率将毫无意义。
    作为一个简单的检查,我查看了8180 Xeon(我能找到的最接近的)有 6 个内存通道,而您的笔记本电脑 CPU 将(希望)设置 2 个通道(或者可能设计不当而只有一个)。服务器的内存带宽是笔记本电脑的 3 倍。这将对内存密集型任务产生巨大的影响。
  • 硬盘。更快的硬盘、SDD 等可以在将数据传送到内存以供 CPU 处理方面产生很大的不同。SSD 寻找少量数据的速度要快几个数量级,批量传输的速度也快得多。NVMe 再次变得更快。服务器通常使用 RAID 进行备份,或者可以设置为原始速度。虽然它们都可能是 NVMe,但服务器场很可能在 RAID 0 或 01 中拥有企业级磁盘,并且比您的单个磁盘更快,特别是在希望跨 VM 影响最小的共享机器上。
  • 热限制。基准测试,尤其是在笔记本电脑和超便携机器上,往往只能持续足够长的时间才能看到性能的初始提升。随着时间的推移,由于风扇跟不上热量输出,蓄热器会变满,并且初始涡轮增压速度下降到“正常”峰值时钟频率。这可能会扭曲基准测试结果,并使笔记本电脑看起来比在长期负载下的性能要好得多。服务器往往有过度指定(和响亮)的冷却系统来确保性能,笔记本电脑是为安静的家庭舒适度而设计的,而风扇的功率要低得多。您在基准测试中看到的可能与您面前的热限制不同,您的可能不会表现得那么好,并且可能会更快地受到限制。
  • 瓶颈。服务器的 I/O 数量将远多于笔记本电脑。更多的 PCIe 通道、更多的专用 IO 端口和更高的外设带宽意味着更多的数据沿着无争议的路径传输。多个 PCIe 设备在连接到 16 通道 CPU 的多路复用器上争用时间将比具有 40 多个专用通道的 CPU 慢。
  • 核心。拥有更多内核不仅会影响您在一个内核上执行的任务,而且意味着这些任务不会为时间而战。权衡是,随着更多内核争夺总线时间,更容易达到内存带宽限制。
  • 缓存。服务器 CPU 往往具有更大的 CPU 缓存。虽然这更像是一种优化,但较大的缓存确实意味着更少的时间进入内存,并且与较小的缓存相比,允许 CPU 达到其峰值性能。单核基准测试可能足够小以适应大多数缓存大小,因此不会告诉您系统的其余部分。
  • 图形。与 PCIe/内存总线争用相关,您的笔记本电脑将执行图形工作,最有可能使用 iGPU。这意味着您的系统内存正在被使用(并且内存带宽被盗)以驱动图形显示。服务器可能没有这些,最有可能是计算集群中的无头节点。服务器的图形开销要少得多。

消费级 CPU 确实很强大,但服务器级 CPU 对更广泛的系统具有更多的逻辑、控制和带宽。不过,一般来说,这很好。我们不希望 15 瓦处理器的性能与具有 140 瓦功率预算的贵 10 倍的 CPU 相同。额外的功率预算提供了更多的自由。

如果服务器 CPU 具有与台式机或笔记本电脑 CPU 相同的性能,那么两者之间就不会有区别。

只是为了进一步说明这一点:类似的单核分数只是告诉您,在理想条件下,这些内核具有合理的可比性。从理论上讲,它们在性能方面可能接近,但它并没有告诉您有关更广泛的系统以及 CPU 在与其他组件绑定时的能力的任何信息。单核速度人为地集中在系统中的一个小点上,这比系统的大多数正常使用会遇到的要多。

有关为什么一个系统比另一个系统“更好”的更多信息,您需要更多地查看所谓的“真实世界”基准测试,它会显示(仍然是人为的,但)更具可比性的系统性能指标,并希望给出一些可能存在瓶颈的想法. 更好的是,您进行的那种测试表明对于该工作负载,具有底层架构和组件的服务器类系统要好得多。

  • 一个很好的答案。在这种情况下,热节流将是这个问题的关键。我记得我博士的“旧”时光,我的带 i7-4600U 的超极本的运行速度是带 i7-3770 的台式机的 4 倍,运行我编写的代码但只运行了大约 5 秒。一旦 CPU 升温,它的速度可能减半或减慢。-> 基本上,U 处理器专为“突发使用”而设计,在这种情况下它们表现良好,但实际上受到其热封套和可用冷却的极大限制。相比之下,服务器和台式机 CPU 将围绕更连续的使用(包括冷却)进行设计。 (7认同)

mrk*_*rks 10

添加到 Mokubai 的优秀答案:

  • 指令集扩展。某些扩展,例如 AVX-512,在服务器处理器(例如问题中提到的 SKX 处理器)中可用,但在消费类处理器中不可用(或仅在稍后)。例如,问题中的 Coffee Lake 消费者 CPU 不支持 AVX-512。我不认为编译器受此影响太大,但是如果您要执行某些数字任务,包括科学计算或机器学习,这可能会导致差异。

  • 核心互连。与单线程任务无关,但当使用多个内核时,互连类型会影响内核相互通信的“速度”。消费者处理器使用环形互连,而服务器处理器首先使用网状互连


小智 7

Intel Corporation 的Intel Xeon Platinum 8151 规格

英特尔公司的英特尔 i5-8259U 规格

  • 看来至强有 38.5 MB L3 缓存
  • Intel Core i5-8259U 似乎只有 6 MB Intel® Smart Cache

处理器缓存是处理器存储最近写入或读取的值而不是依赖于主系统内存的地方。

  • 缓存被设计成各种形状和大小,但具有几个使其易于利用的经典特性。缓存通常具有较低的集合关联性,并使用组选择器。关联缓存
  • 在典型的处理器缓存中,给定的物理(或逻辑,取决于设计)地址必须映射到缓存中的某个位置。它们通常使用称为缓存行的内存单元,其大小范围从 16 字节的小行到更典型的 64 字节甚至 128 字节的行。
  • 如果两个源地址(或缓存行)映射到同一个缓存地址,则必须将其中之一从缓存中逐出。
  • 驱逐意味着丢失的源地址必须在下次使用时从内存中获取。在完全关联的缓存(也称为完全关联的内存或 CAM)中,源地址可以映射到缓存内的任何位置。这会产生较高的缓存命中率,因为驱逐发生的频率较低。
  • 这种类型的缓存很昂贵(就芯片空间而言)并且实施速度较慢。提高缓存命中的延迟通常不值得在缓存未命中惩罚中节省一点点,否则...您可以在此处阅读更多内容

更高总线速率的 DDR4 也有助于提高速度。更不用说 Xeon 具有事务同步扩展而 i5 没有。

它们不属于同一类处理器,但希望以上信息对您有所帮助,英特尔公司的链接有助于验证我的回答的有效性。


sle*_*man 4

鉴于您描述的任务、编译 Bable 项目以及所涉及的 CPU,我想我知道性能差异的根源。我想早点回答,但必须做一些研究来证实我的预感。

首先,让我们描述一下您施加在系统上的负载。

Babel.js 被编写为单线程、单进程编译器,主要利用异步 I/O 来实现并行性(至少我在 google 上搜索到的任何内容都表明它使用工作线程)。由于它是一个从磁盘编译文件的编译器,因此其执行的很大一部分涉及等待来自磁盘的数据。这给我们带来了以下工作量:

  1. 单线程,因此多核或超线程对编译没有显着影响,但有一个警告:

  2. Node.js 使用工作线程来处理磁盘 I/O,但除了两个或四个硬件线程之外,多核没有额外的优势(请参阅: https: //nodejs.org/en/docs/guides/dont-block-the -事件循环/

  3. 大多数并行性发生在 I/O 级别。Babel 将尝试并行读取尽可能多的文件。

i5 和 Xeon 在第 1 点和第 2 点上具有相当的可比性。因此,让我们看看 CPU 如何处理第 3 点:服务 Babel 的并行文件读取请求。

这是两个系统之间的第一个重大区别:

  • Core i5 8259 有 16 个 PCI 通道

  • Xeon 8151 有 48 个 PCI 通道

很明显,Xeon 可以比 i5 处理更多的并行 I/O 操作。当 I/O 数量多于可用内存传输通道数量时,操作系统的处理方式与任务数量多于可用硬件线程数量时的处理方式相同:它将它们排队并强制它们轮流执行。

接下来我想知道 NVME 是否真的可以使用多个通道。这是我发现另一个有趣的事实的地方。NVME 标准允许卡使用最多 4 个 PCI 通道(物理上分配了许多连接),但有些卡仅使用 2 个,而其他卡则使用 4 个。因此,并非所有 NVME 卡都是一样的。仅此一项就可以让 Babel 以几乎双倍的带宽并行复制到 RAM 的文件数量增加一倍。

它还取决于 NVME 插槽如何连接到 CPU。Core i5 只有 16 个 PCI 通道,毫无疑问会为 GPU 保留至少 8 个通道。只剩下 8 个可以在其他设备之间共享。这意味着有时您的 NVME 卡必须与 Wifi 或其他硬件共享带宽。这会减慢速度。

您的 NVME 甚至可能没有直接连接到 CPU 的 PCI 通道。Macbook 实际上可能为 GPU 保留所有 16 个通道,并通过其南桥(可能有额外的 PCI 通道)连接到 NVME。我不知道 Macbook 是否会这样做,但这可能会进一步降低性能。

相比之下,Xeon 拥有大量通道,使主板设计人员能够更自由地创建真正快速的 I/O 平台。此外,AWS服务器通常没有安装GPU,因此不需要预留任何通道供GPU使用。再说一次,我个人并不了解 AWS 服务器的实际架构,但有可能创建一个在编译 Babel 项目时性能优于 Macbook 的服务器。

所以最终使EC2实例能够胜过Macbook的主要因素是:

  1. CPU直接支持的PCI通道数

  2. NVME驱动器支持的PCI通道数

  3. NVME 通道如何连接到 CPU

其他可能起作用的因素包括:

  1. I/O 总线的速度(PCI2 与 PCI3 等)

  2. 内存速度

  3. 可用 DMA 通道的数量(仅此一项就需要很长的答案,所以我有点跳过它,但推理与 PCI 通道类似)