程序何时会受益于预取和非临时加载/存储？

我用这个做了测试

    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);
        }
    }

结果很奇怪。

1. 无论有多少时间a_single_chain_computation需要注意的是，加载延迟并未被隐藏。
2. 更重要的是，随着我添加更多计算，所花费的额外总时间也会增加。 （与单个v = _mm_mul_ps(v, v)，预取大约节省 0.60 - 0.57 = 0.03s。并与 16v = _mm_mul_ps(v, v)，大约节省 1.1 - 0.75 = 0.35s。为什么？）
3. 无论是否预取，非临时加载/存储都会降低性能。 （我可以理解负载部分，但为什么商店也能理解？）

您需要在这里区分两个不同的东西（不幸的是它们具有相似的名称）：

• 非临时预取 - 这将预取该行，但在填充缓存时将其写入最近最少使用的行，因此当您下次使用同一组时，它将成为第一个被逐出的行。这让你有足够的时间来实际使用它（除非你非常不幸），但不会浪费超过该集合中的一个路径，因为下一个预取将取代它。顺便说一句，关于您上面的评论 - 每次预取都会污染 L3 缓存，它是包容性的，所以如果没有它，您就无法逃脱。

• 非临时（流）加载/存储 - 这也不会污染缓存，但使用完全不同的机制使它们不可缓存（以及写入组合）。这确实会对性能造成影响即使你真的不再需要这些行，因为可缓存写入可以在缓存中保留缓冲直到被逐出，所以您不必立即将其写出。对于不可缓存的情况，在某些情况下，它可能会干扰您的内存带宽。另一方面，您可以获得写入组合和弱排序的好处，这可能会给您带来一些优势（在某些情况下）。这里的底线是，您应该仅在有帮助时才使用它，不要认为它会神奇地提高性能（现在没有什么能做到这一点......）

关于你的问题——

1. 您的预取应该可以工作，但还不够早，无法产生影响。尝试更换i+1数量较多。实际上，甚至可以进行一次扫描，看看您应该提前查看多少元素，这会很有趣。

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

3. 正如我所说 - 您的存储不会受益于较低级别缓存中的缓冲，并且必须刷新到内存。这就是流媒体商店的缺点。当然，它是特定于实现的，因此它可能会有所改进，但目前并不总是有效。