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)
结果很奇怪.
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.35s.为什么?)你需要在这里分开两个不同的东西(遗憾的是它们的名字相似):
非时间预取 - 这将预取行,但在填充缓存时将其写为最近最少使用的行,因此当您下次使用相同的集时,它将成为第一个排除行.这让你有足够的时间来实际使用它(除非你非常不走运),但是不会浪费多于一个方法,因为下一个预取将会替换它.顺便说一句,关于你上面的评论 - 每个预取都会污染L3缓存,它是包容性的,所以没有它你就无法逃脱.
非时间(流式)加载/存储 - 这也不会污染缓存,但使用完全不同的机制使它们不可缓存(以及写入组合).即使你真的不再需要这些线路,这确实会对性能造成损害,因为可缓存的写入可以在缓存中保持缓存,直到被驱逐为止,因此您不必立即将其写出来.使用uncacheables,在某些情况下,它可能会干扰你的mem BW.另一方面,您可以获得写入组合和弱排序的好处,这可能会给您一些优势.这里的底线是你应该只在它有用时使用它,不要假设它神奇地改善了性能(现在没有什么呢......)
关于你的问题 -
你的预取应该有效,但现在还不足以产生影响.尝试用i+1更大的数字替换.实际上,甚至可以进行一次扫描,看看你应该先看多少元素会很有趣.
我猜这与1相同 - 16 muls你的迭代足够长,预取工作
正如我所说的 - 你的商店不会有低级缓存缓冲的好处,而且必须刷新内存.这是流媒体商店的缺点.它当然是具体实现的,所以它可能会有所改进,但目前它并不总是有效的.
| 归档时间: |
|
| 查看次数: |
1622 次 |
| 最近记录: |