12

我用这个做了一个测试

    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.03 秒。使用 16 v = _mm_mul_ps(v, v)，它节省大约 1.1 - 0.75 = 0.35 秒。为什么？）
  3. 非临时加载/存储在有或没有预取的情况下都会降低性能。（我可以理解加载部分，但为什么也要存储？）
4

2 回答 2

8

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

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

  • 非临时（流式）加载/存储 - 这也不会污染缓存，但使用完全不同的机制使它们不可缓存（以及写入组合）。即使您真的不再需要这些行，这确实会对性能产生影响，因为可缓存写入可以在缓存中保持缓冲直到被驱逐，因此您不必立即将其写出。使用不可缓存的内容，在某些情况下它可能会干扰您的内存 BW。另一方面，您可以从写组合和弱排序中获益，这可能会给您带来一些优势。这里的底线是你应该只在它有帮助的时候使用它，不要假设它神奇地提高了性能（现在什么都没有......）

关于你的问题——

  1. 您的预取应该可以工作，但还不足以产生影响。尝试用i+1更大的数字替换。实际上，甚至可以进行扫描，看看您应该提前查看多少元素会很有趣。

  2. 我猜这与 1 相同 - 使用 16 muls，您的迭代时间足够长，可以让预取工作

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

于 2013-10-19T11:16:06.223 回答
1

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

仅当您不打算在不久的将来访问此内存时，流式加载和存储才是好的。它们主要针对通常在处理图形表面时发现的未缓存回写 (WB) 内存。显式预完善可能在一种架构（CPU 模型）上运行良好，但对其他模型有负面影响，因此在优化时将它们作为最后的选择。

于 2013-11-21T15:34:50.160 回答