是否有人知道尝试在App Direct模式（即非易失性内存）中使用Intel Optane DC Memory（DCPMM）来使用Write Through（WT）或Un-Cacheable对其进行读写操作的缺点（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高管。我认为UC还会阻止您使用NT存储进行全行写入。它还会完全破坏读取性能，因此我认为这不值得考虑。
WT也许值得考虑作为clwb的替代方案（假设它实际上可与NV存储器一起使用），但是您仍必须对存储的编译时重新排序保持谨慎。 _mm_clwb大概是编译器的内存屏障，可以防止此类问题。
但是，在商店繁重的工作负载中，您会期望写入速度严重下降。每个核心的内存带宽在很大程度上受未决请求数量的限制。使每个请求更小（仅8个字节或其他内容而不是整行）不会使它明显更快。大多数时间是通过内存层次结构获取请求，并等待地址线选择正确的位置，而不是通过内存总线进行实际的突发传输。 （这是流水线，因此对于同一DRAM页有多个全行请求，内存控制器可以将其大部分时间用于传输数据，而不是等待，我想。Optane / 3DXPoint的速度不及DRAM快，因此可能会有更多的等待时间。）
因此，例如，除非您（或编译器）进行向量化，否则连续存储int64_t或double将在每个64字节高速缓存行中占用8个单独的存储。使用WT而不是WB + clwb，我想它会慢大约8倍。这不是基于有关Optane DC PM的任何实际性能细节；我还没有看到内存延迟/带宽数量，也没有看过WT性能。不过，我偶尔看到的论文将常规DDR DRAM上的真实Intel硬件上的WT和WB缓存与合成工作负载进行了比较。我认为，如果您的代码没有多次写入同一缓存行，则可以使用。 （但是通常这是您要进行并优化的事情，因为WB缓存使其非常便宜。）
如果有AVX512，则可以进行全行64字节存储，如果确保它们对齐。 （无论如何，您通常都希望获得512位向量的性能）。