Question

我用这个

进行了测试

    for (i32 i = 0; i < 0x800000; ++i)
    {
        // Hopefully this can disable hardware prefetch
        i32 k = (i * 997 & 0x7FFFFF) * 0x40;

        _mm_prefetch(data + ((i + 1) * 997 & 0x7FFFFF) * 0x40, _MM_HINT_NTA);

        for (i32 j = 0; j < 0x40; j += 0x10)
        {
            //__m128 v = _mm_castsi128_ps(_mm_stream_load_si128((__m128i *)(data + k + j)));
            __m128 v = _mm_load_ps((float *)(data + k + j));

            a_single_chain_computation

            //_mm_stream_ps((float *)(data2 + k + j), v);
            _mm_store_ps((float *)(data2 + k + j), v);
        }
    }

结果很奇怪。

无论a_single_chain_computation花费多少时间，都不会隐藏加载延迟。
而且，随着我添加更多计算，额外的总时间会增加。（使用单个v = _mm_mul_ps(v, v)，预取可节省约0.60 - 0.57 = 0.03s。使用16 v = _mm_mul_ps(v, v)，可节省约1.1 - 0.75 = 0.35s。为什么？）
非临时加载/存储会在预取或不预取的情况下降低性能。（我可以理解负载部分，但为什么还要存储？）

Answer 1

你需要在这里分开两个不同的东西（遗憾的是它们的名字相似）：

非临时预取 - 这将预取该行，但在填充缓存时将其写为最近最少使用的行，因此当您下次使用相同的集时，它将成为第一个排除行。这让你有足够的时间来实际使用它（除非你非常不走运），但是不会浪费多于一个方法，因为下一个预取将会替换它。顺便说一句，关于你上面的评论 - 每次预取都会污染L3缓存，它是包容性的，所以没有它就无法逃脱。
非时间（流）加载/存储 - 这也不会污染缓存，但使用完全不同的机制使它们不可缓存（以及写入组合）。即使你真的不再需要这些行，这确实会对性能造成损失，因为可缓存的写入可以在缓存中保持缓存，直到被驱逐，所以你没有马上把它写出来。使用uncacheables，在某些情况下，它可能会干扰你的mem BW。另一方面，您可以获得写入组合和弱排序的好处，这可能会给您一些优势。这里的底线是你应该只在它有用的时候使用它，不要假设它神奇地改善了性能（现在没有什么呢。）

关于你的问题 -

您的预取应该有效，但现在还不足以产生影响。尝试用更大的数字替换i+1。实际上，甚至可以进行一次扫描，看看你应该先看多少元素会很有趣。

我猜这与1相同 - 有16个muls，你的迭代足够长，预取工作

正如我所说 - 你的商店不会有低级缓存缓冲的好处，而且必须刷新内存。这是流媒体商店的缺点。它当然是具体的实现，所以它可能会有所改进，但目前它并不总是有效。

Answer 2

如果您的计算链非常短，并且如果您正在按顺序读取内存，那么CPU将自行预取并实际工作得更快，因为它的解码器工作量较少。

仅当您不打算在不久的将来访问此内存时，流加载和存储才有用。它们主要针对处理图形表面时通常会发现的未缓存的回写（WB）内存。显式预处理可以在一个体系结构（CPU模型）上很好地工作，并对其他模型产生负面影响，因此在优化时将它们用作最后的选择。

当程序将受益于prefetch＆amp;非临时加载/存储？

2 个答案: