我用这个做了测试
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.35 秒。为什么?) - 无论有无预取,非临时加载/存储都会降低性能。 (我能理解负载部分,但为什么存储也一样?)
最佳答案
你需要在这里分开两个不同的东西(不幸的是它们有一个相似的名字):
非临时预取 - 这将预取该行,但当它填满缓存时将其写为最近最少使用的行,因此当您下次使用同一组时,它将成为第一个被逐出的行。这让您有足够的时间来实际使用它(除非您非常不幸),但不会浪费超过该集合的一种方式,因为下一个预取将取代它。顺便说一句,关于你上面的评论 - 每次预取都会污染 L3 缓存,它是包容性的,所以你不能没有它。
非临时(流式)加载/存储 - 这也不会污染缓存,但使用完全不同的机制使它们不可缓存(以及写入组合)。这确实会对性能产生影响即使您真的不再需要这些行,因为可缓存的写入可以在缓存中保持缓冲直到被驱逐,所以您没有马上写出来。使用 uncacheables 你可以,在某些情况下它可能会干扰你的 mem BW。另一方面,您可以获得写组合和弱排序的好处,这可能会给您带来一些优势。这里的底线是只有在它有帮助时才应该使用它,不要假设它会神奇地提高性能(现在没有人这样做......)
关于您的问题-
您的预取应该有效,但还不足以产生影响。尝试用更大的数字替换
i+1
。实际上,甚至可以扫一扫,看看您应该提前查看多少元素会很有趣。我猜这与 1 相同 - 有 16 个 muls,您的迭代足够长以进行预取
正如我所说 - 您的存储将无法在较低级别的缓存中进行缓冲,并且必须刷新到内存中。这是流媒体商店的缺点。当然,它是特定于实现的,因此它可能会有所改进,但目前并不总是有效。
关于c - 程序何时会受益于预取和非临时加载/存储?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/17312823/