Mathnet Numerics with Intel MKL 在 Intel Xeon Gold 上的运行速度比旧的 i7-7700HQ 笔记本电脑慢得多

问题描述

我有几个函数使用 MathNet Numerics + Intel MKL 提供程序进行矩阵计算。矩阵不是太大,比如 40x100,并且操作涉及一些伪逆、特征值和类似的线性代数。

然而,创建了一个小型基准测试应用程序来运行 1000 次计算,结果证明我们新的 Intel Xeon Gold 6226R(16 核,32 线程)运行计算比我的旧 i7 7700HQ(4 核, 8 线程)笔记本电脑,比我能测试的基本上所有 5-6 岁的旧电脑都要慢。

我尝试过“原生英特尔 MKL”和“托管”多线程提供程序。 MKL 是 ~2x ,而托管的可能快 10%。

此外,在 i7 笔记本电脑上运行测试时,我的 cpu 利用率约为 80%,并且运行频率约为 3.5GHz。但至强将频率降低到约 2GHz 左右,然后使用约 30-40% 的利用率。笔记本电脑 (Windows 10) 和服务器 (Windows Server 2019) 均设置为高性能模式。

我很确定这里应该有一些我遗漏的技巧?

(更新)

如果有人遇到同样的问题,可以通过设置 MKL_ENABLE_INSTRUCTIONS 环境来禁用 AVX512。变量为 AVX2。这在 Xeon 上稍微加快了 MKL:

SET MKL_ENABLE_INSTRUCTIONS=AVX2

但这仍然不如 i7 快。

如果我禁用 MKL 并使用 MathNet Numerics 托管提供程序,然后还使用 Parallel.For 循环并行运行所有内容,则 Xeon 可以击败 i7 的唯一方法在这种情况下,至强的速度提高了约 30%,尽管它的 cpu 使用率仍然没有超过 40%(i7 cpu 已达到极限)。

考虑到它提供了多少额外的内核,还是有点令人失望。

解决方法

许多小矩阵可能意味着如果不进行手动矢量化(不仅仅是在一次调用 MKL 函数内),就很难扩展到大量内核,因此这可以解释 32 与 8 逻辑内核机器上的利用率。 2GHz 可能是该芯片上的最大 AVX-512 频率,您必须检查它以及 MKL 是否正在使用它。 (SIMD instructions lowering CPU frequency)。 512 位向量可能是行或列大小的奇数倍,可能不太好。

您的 Kaby Lake 每个时钟可以运行 2 个 256 位 FMA,并且具有与 Xeon Gold (Skylake) 相同的微架构(在每个内核中),除了 AVX-512 和 256k L2 而不是 1MiB。 Xeon Gold 6226R 确实有 2 个 512 位 FMA 单元(与某些 Xeon-SP 芯片不同),因此它能够将每个内核每个时钟的 FLOPS 提高两倍如果它可以让它们继续工作。 >

英特尔在推出新微架构的服务器版本方面总是至少落后几个月,而且由于他们的 10nm 生产问题,我们直到今年 Ice-Lake Xeons 才拥有真正新的服务器微架构。 Cascade Lake 只是 Skylake-X 上的效率优化(电源/时钟),因此它至少与 Skylake 到 Coffee Lake 的客户端芯片仍然是相同的核心,除了 AVX-512(及其不同的扩展)和那些更大的 L2缓存。


但是,如果您的工作负载主要不受每核 FMA 吞吐量的限制,并且受其他操作(如 FP 除法)的吞吐量的限制,那么您的 Kaby Lake 每时钟速度更快,并且时钟更高,这是完全正常的。

此外,与大型 Xeon 上的网状互连相比,像您的笔记本电脑这样的“客户端”芯片具有更低的核心间延迟,如果 MKL 尝试并行化几乎不值得的问题,这可能会减少小矩阵的开销。 (Why is Skylake so much better than Broadwell-E for single-threaded memory throughput?)

如果您并行执行大量这些矩阵运算(每个线程一个),而不是尝试并行化一个又一个较小的矩阵运算(即减少一个通过分配工作来操作;而是让一个内核为一个操作完成所有工作,以便数据在其 L1d 或 L2 缓存中保持热状态)。

相关问答

Selenium Web驱动程序和Java。元素在(x,y)点处不可单击。其...
Python-如何使用点“。” 访问字典成员?
Java 字符串是不可变的。到底是什么意思?
Java中的“ final”关键字如何工作?(我仍然可以修改对象。...
“loop:”在Java代码中。这是什么,为什么要编译?
java.lang.ClassNotFoundException:sun.jdbc.odbc.JdbcOdbc...