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

我做了一个测试

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 v = _mm_mul_ps(v, v) 。并且使用16 v = _mm_mul_ps(v, v) ,它可以节省大约1.1 – 0.75 = 0.35s。为什么?)
  3. 非暂时加载/存储会在预取或不预取的情况下降低性能。 (我可以理解负载部分,但为什么还要存储?)

你需要在这里分开两个不同的东西(不幸的是有类似的名字):

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

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

关于你的问题 –

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

  2. 我猜这与1相同 – 有16个muls,你的迭代足够长,以便预取工作

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

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

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