写入和读取的持久内存缓存策略
Persistent memory cache policy to write and read
是否有人知道在 App Direct 模式（即作为非易失性存储器）中尝试使用 Intel Optane DC Memory (DCPMM) 来写入或读取 to/from 它的任何缺点(WT) 或不可缓存 (UC) 内存策略？这个想法是使用常规内存作为非易失性（在发生故障时数据不会丢失），具有脏缓存行并不理想，因为它是易失性的。有多个链接显示使用回写 (WB) 或写组合 (WC) 与非临时访问 (NTA) 指令的示例，还使用 WB 和 CLFLUSHOPT 或 CLWB 写指令。与使用 WB/WC 相比，使用 WT/UC 时，除了带宽，没有将整个缓存行写入内存之外，还有其他重要的缺点吗？
（这主要是猜测，我没有对 Optane DC PM 进行任何性能测试，只是偶尔阅读有关 DRAM 的 UC 或 WT。但我认为对它们的一般工作方式已经了解得足够多了对于许多工作负载来说可能不是一个好主意。）
进一步阅读有关 Optane DC PM DIMM 的信息：https://thememoryguy.com/whats-inside-an-optane-dimm/ - 它们包括像 SSD 一样的磨损均衡重新映射层。
也相关：英特尔论坛上的 When I test AEP memory, I found that flushing a cacheline repeatedly has a higher latency than flushing different cachelines. I want to know what caused this phenomenon. Is it wear leveling mechanism ?。这表明 重复写入同一缓存行可能比您预期的还要糟糕。
我认为 UC 还意味着会伤害 OoO exec 的强排序。我认为 UC 还会阻止您使用 NT 存储进行全行写入。它还会完全破坏读取性能，所以我认为不值得考虑。
WT 可能值得考虑作为 clwb 的替代方案（假设它实际上适用于 NV 内存），但您仍然需要注意存储的编译时重新排序。 _mm_clwb 大概是一个编译器内存屏障，可以防止此类问题。
不过，在存储繁重的工作负载中，写入速度可能会严重下降。每核内存带宽在很大程度上受到未完成请求数量的限制。使每个请求更小（只有 8 个字节或其他而不是整行）不会使其明显更快。绝大多数时间是通过内存层次结构获取请求，并等待地址线到达 select 正确的位置，而不是通过内存总线进行实际的突发传输。 （我认为这是流水线式的，因此对于同一个 DRAM 页面的多个全线请求，内存控制器可以将大部分时间用于传输数据，而不是等待。Optane / 3DXPoint 不如 DRAM 快，因此可能会有更多等待.)
因此，例如，存储连续的 int64_t 或 double 将在每个 64 字节缓存行中占用 8 个单独的存储，除非您（或编译器）进行矢量化。使用 WT 而不是 WB + clwb，我猜这会慢 8 倍左右。 这不是基于有关 Optane DC PM 的任何实际性能细节；我没有看到内存延迟/带宽数字，也没有查看 WT 性能。不过，我偶尔会看到一些论文将合成工作负载与 WT 与常规 DDR DRAM 上的真实英特尔硬件上的 WB 缓存进行比较。我认为如果对同一缓存行的多次写入对于您的代码来说不是典型的，那么它是可用的。 （但通常这是你想要做和优化的事情，因为 WB 缓存使其非常便宜。）
如果您有 AVX512，则可以进行全行 64 字节存储，前提是您确保它们对齐。 （无论如何，您通常希望使用 512 位向量来提高性能）。
是否有人知道在 App Direct 模式（即作为非易失性存储器）中尝试使用 Intel Optane DC Memory (DCPMM) 来写入或读取 to/from 它的任何缺点(WT) 或不可缓存 (UC) 内存策略？这个想法是使用常规内存作为非易失性（在发生故障时数据不会丢失），具有脏缓存行并不理想，因为它是易失性的。有多个链接显示使用回写 (WB) 或写组合 (WC) 与非临时访问 (NTA) 指令的示例，还使用 WB 和 CLFLUSHOPT 或 CLWB 写指令。与使用 WB/WC 相比，使用 WT/UC 时，除了带宽，没有将整个缓存行写入内存之外，还有其他重要的缺点吗？
（这主要是猜测，我没有对 Optane DC PM 进行任何性能测试，只是偶尔阅读有关 DRAM 的 UC 或 WT。但我认为对它们的一般工作方式已经了解得足够多了对于许多工作负载来说可能不是一个好主意。）
进一步阅读有关 Optane DC PM DIMM 的信息：https://thememoryguy.com/whats-inside-an-optane-dimm/ - 它们包括像 SSD 一样的磨损均衡重新映射层。
也相关：英特尔论坛上的 When I test AEP memory, I found that flushing a cacheline repeatedly has a higher latency than flushing different cachelines. I want to know what caused this phenomenon. Is it wear leveling mechanism ?。这表明 重复写入同一缓存行可能比您预期的还要糟糕。
我认为 UC 还意味着会伤害 OoO exec 的强排序。我认为 UC 还会阻止您使用 NT 存储进行全行写入。它还会完全破坏读取性能，所以我认为不值得考虑。
WT 可能值得考虑作为 clwb 的替代方案（假设它实际上适用于 NV 内存），但您仍然需要注意存储的编译时重新排序。 _mm_clwb 大概是一个编译器内存屏障，可以防止此类问题。
不过，在存储繁重的工作负载中，写入速度可能会严重下降。每核内存带宽在很大程度上受到未完成请求数量的限制。使每个请求更小（只有 8 个字节或其他而不是整行）不会使其明显更快。绝大多数时间是通过内存层次结构获取请求，并等待地址线到达 select 正确的位置，而不是通过内存总线进行实际的突发传输。 （我认为这是流水线式的，因此对于同一个 DRAM 页面的多个全线请求，内存控制器可以将大部分时间用于传输数据，而不是等待。Optane / 3DXPoint 不如 DRAM 快，因此可能会有更多等待.)
因此，例如，存储连续的 int64_t 或 double 将在每个 64 字节缓存行中占用 8 个单独的存储，除非您（或编译器）进行矢量化。使用 WT 而不是 WB + clwb，我猜这会慢 8 倍左右。 这不是基于有关 Optane DC PM 的任何实际性能细节；我没有看到内存延迟/带宽数字，也没有查看 WT 性能。不过，我偶尔会看到一些论文将合成工作负载与 WT 与常规 DDR DRAM 上的真实英特尔硬件上的 WB 缓存进行比较。我认为如果对同一缓存行的多次写入对于您的代码来说不是典型的，那么它是可用的。 （但通常这是你想要做和优化的事情，因为 WB 缓存使其非常便宜。）
如果您有 AVX512，则可以进行全行 64 字节存储，前提是您确保它们对齐。 （无论如何，您通常希望使用 512 位向量来提高性能）。