是否有人知道尝试在 App Direct 模式下（即作为非易失性内存）使用英特尔傲腾 DC 内存（DCPMM）使用直写（WT）或不可缓存（ UC) 内存策略？这个想法是使用常规内存作为非易失性（在发生故障时数据不会丢失），脏缓存行并不理想，因为它是易失性的。有多个链接显示使用写回 (WB) 或写组合 (WC) 与非临时访问 (NTA) 指令的示例，也使用 WB 和 CLFLUSHOPT 或 CLWB 写指令。与 WB/WC 相比，在使用 WT/UC 时没有将整个缓存行写入内存，除了带宽之外还有其他重要的缺点吗？
问问题
397 次
1 回答
2
（这主要是猜测，我没有使用 Optane DC PM 进行任何性能测试，只是偶尔阅读有关 DRAM 的 UC 或 WT。但我认为对于它们的一般工作方式已经有足够的了解，可以说这可能是一个坏主意许多工作负载。）
有关 Optane DC PM DIMM 的进一步阅读：https ://thememoryguy.com/whats-inside-an-optane-dimm/ - 它们包括一个磨损均衡重新映射层，如 SSD。
还相关：当我测试 AEP 内存时，我发现反复刷新缓存线比刷新不同的缓存线具有更高的延迟。我想知道是什么导致了这种现象。是磨损均衡机制吗？在英特尔论坛上。这表明重复写入同一高速缓存行可能比您预期的还要糟糕。
我认为 UC 还意味着强排序会伤害 OoO 执行官。我认为 UC 还会阻止您使用 NT 存储进行全行写入。它也会完全破坏读取性能，所以我认为不值得考虑。
WT 可能值得考虑作为替代方案clwb（假设它实际上适用于 NV 内存），但您仍然必须小心存储的编译时重新排序。 _mm_clwb大概是可以防止此类问题的编译器内存屏障。
但是，在存储繁重的工作负载中，您会预期写入速度会严重下降。每核内存带宽受到未完成请求数量的极大限制。使每个请求更小（只有 8 个字节或其他内容而不是一整行）不会使其明显更快。绝大多数时间是通过内存层次结构获取请求，并等待地址线选择正确的位置，而不是通过内存总线进行实际的突发传输。（这是流水线的，因此对于同一个 DRAM 页面的多个全线请求，内存控制器可以将大部分时间用于传输数据，而不是等待，我认为。Optane / 3DXPoint 不如 DRAM 快，因此可能需要更多等待.)
因此，例如，除非您（或编译器）矢量化，否则每个 64 字节缓存行存储连续int64_t或double需要 8 个单独的存储。使用 WT 而不是 WB + clwb，我猜这会慢 8 倍。 这不是基于有关 Optane DC PM 的任何真实性能细节；我没有看到内存延迟/带宽数字，也没有看过 WT 性能。不过，我偶尔会看到一些论文比较了合成工作负载与 WT 与 WB 在常规 DDR DRAM 上的真实英特尔硬件上的缓存。如果您的代码不典型地多次写入同一缓存行，我认为它是可用的。（但通常这是您想要做和优化的事情，因为 WB 缓存使其非常便宜。）
如果您有 AVX512，则可以进行全行 64 字节存储，前提是确保它们对齐。（无论如何，您通常都希望获得 512 位向量的性能）。
于 2020-01-03T06:55:17.873 回答