首页
学习
活动
专区
工具
TVP
发布
社区首页 >问答首页 >预取指令

预取指令
EN

Stack Overflow用户
提问于 2010-06-26 14:06:51
回答 3查看 8.7K关注 0票数 21

似乎预取使用的一般逻辑是,如果代码在预取指令完成其操作之前忙于处理,则可以添加预取。但是,似乎如果使用了太多的预取指令,那么它将影响系统的性能。我发现我们首先需要在没有预取指令的情况下拥有工作代码。稍后,我们需要在代码的不同位置进行各种预取指令的组合,并进行分析,以确定由于预取而实际可以改进的代码位置。有没有更好的方法来确定应该使用预取指令的确切位置?

EN

回答 3

Stack Overflow用户

回答已采纳

发布于 2010-06-26 15:05:08

在大多数情况下,预取指令几乎没有好处,在某些情况下甚至会适得其反。大多数现代CPU都有一个自动预取机制,该机制工作得足够好,以至于添加软件预取提示几乎不会实现,甚至会干扰自动预取,实际上可能会降低性能。

在极少数情况下,例如当您正在流式传输大块数据,而您对其进行的实际处理非常少时,您可能会设法使用软件启动的预取来隐藏一些延迟,但这是非常困难的-您需要在使用数据之前启动数百个周期的预取-做得太晚了,您仍然会得到缓存未命中,做得太早,您的数据可能会在您准备使用它之前从缓存中逐出。这通常会将预取放在代码的一些不相关的部分,这对模块化和软件维护是不好的。更糟糕的是,如果您的体系结构发生变化(新的CPU、不同的时钟速度等),导致DRAM访问延迟增加或减少,您可能需要将预取指令移动到代码的另一部分以保持它们的有效性。

无论如何,如果你觉得你真的必须使用预取,我建议在任何预取指令周围使用#ifdefs,这样你就可以在有或没有预取的情况下编译你的代码,看看它是否确实有助于(或阻碍)性能,例如

#ifdef USE_PREFETCH
    // prefetch instruction(s)
#endif

不过,总的来说,我建议在你完成了所有更高效和更明显的事情之后,把软件预取作为最后的微优化手段。

票数 19
EN

Stack Overflow用户

发布于 2012-05-02 08:08:11

即使考虑预取代码,性能肯定已经是一个问题了。

1:使用代码分析器。尝试在没有分析器的情况下使用预取是浪费时间。

2:每当你在一个异常缓慢的关键位置发现一条指令时,你就有了一个预取的候选者。通常,实际的问题出在慢的那条线路之前的内存访问上,而不是分析器指出的慢的那条线路上。找出是什么内存访问导致了问题(并不总是那么容易)并预取它。

3再次运行您的分析器,看看是否有什么不同。如果它不把它拿出来的话。有时,我通过这种方式将循环速度提高了300%以上。如果您有一个以非顺序方式访问内存的循环,那么它通常是最有效的。

我完全不同意它在现代CPU上没有那么有用,我发现完全相反,尽管在旧CPU上预取大约100条指令是最佳的,但现在我认为这个数字更接近500条。

票数 6
EN

Stack Overflow用户

发布于 2010-07-17 05:26:41

当然,你必须进行一些实验,但并不是说你需要在需要数据之前获取一些houndred周期(100-300)。L2缓存足够大,预取的数据可以在那里停留一段时间。

这种预取在a循环(当然是几个houndred循环)之前是非常有效的,特别是如果它是内部循环,并且循环每秒启动上千次。

此外,对于速度较低的LL实现或树实现,预取可以获得一个可衡量的优势,因为CPU不知道数据很快就会被需要。

但请记住,预取指令会消耗一些解码器/队列带宽,因此过度使用它们会因为这个原因而损害性能。

票数 1
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/3122915

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档