当程序将受益于预取和非临时加载/存储?

Blu*_*rer 11 c sse prefetch temporal

我做了一个测试

    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);
        }
    }
Run Code Online (Sandbox Code Playgroud)

结果很奇怪.

  1. 无论a_single_chain_computation花费多少时间,负载延迟都不会被隐藏.
  2. 而且,随着我添加更多计算,额外的总时间会增加.(使用单个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.为什么?)
  3. 非暂时加载/存储会在预取或不预取的情况下降低性能.(我可以理解负载部分,但为什么还要存储?)

Lee*_*eor 8

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

  • 非时间预取 - 这将预取行,但在填充缓存时将其写为最近最少使用的行,因此当您下次使用相同的集时,它将成为第一个排除行.这让你有足够的时间来实际使用它(除非你非常不走运),但是不会浪费多于一个方法,因为下一个预取将会替换它.顺便说一句,关于你上面的评论 - 每个预取都会污染L3缓存,它是包容性的,所以没有它你就无法逃脱.

  • 非时间(流式)加载/存储 - 这也不会污染缓存,但使用完全不同的机制使它们不可缓存(以及写入组合).即使你真的不再需要这些线路,这确实会对性能造成损害,因为可缓存的写入可以在缓存中保持缓存,直到被驱逐为止,因此您不必立即将其写出来.使用uncacheables,在某些情况下,它可能会干扰你的mem BW.另一方面,您可以获得写入组合和弱排序的好处,这可能会给您一些优势.这里的底线是你应该只在它有用时使用它,不要假设它神奇地改善了性能(现在没有什么呢......)

关于你的问题 -

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

  2. 我猜这与1相同 - 16 muls你的迭代足够长,预取工作

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