预取使用的一般逻辑似乎是可以添加预取，前提是代码忙于处理，直到预取指令完成其操作。但是，如果使用太多的预取指令，似乎会影响系统的性能。我发现我们首先需要有没有预取指令的工作代码。稍后我们需要在代码的各个位置进行预取指令的各种组合并进行分析以确定由于预取而真正可以改进的代码位置。有没有更好的方法来确定应该使用预取指令的确切位置？
最佳答案
在大多数情况下，预取指令几乎没有任何好处，甚至在某些情况下甚至会适得其反。大多数现代 CPU 都有自动预取机制，该机制运行良好，添加软件预取提示效果甚微，甚至会干扰自动预取，实际上会降低性能。
在一些罕见的情况下，例如当您流式传输大数据 block 而几乎没有进行实际处理时，您可能会设法通过软件启动的预取来隐藏一些延迟，但很难做到正确 -在使用数据之前，您需要开始预取几百个周期 - 太晚，您仍然会出现缓存未命中，太早，您的数据可能会在准备使用之前从缓存中逐出。通常这会将预取放在代码的某些不相关部分中，这不利于模块化和软件维护。更糟糕的是，如果您的架构发生变化(新的 CPU、不同的时钟速度等)，导致 DRAM 访问延迟增加或减少，您可能需要将预取指令移至代码的另一部分以保持其有效。
无论如何，如果您觉得确实必须使用预取，我建议在任何预取指令周围使用#ifdef，以便您可以在使用或不使用预取的情况下编译代码，并查看它是否确实有助于(或阻碍)性能，例如
#ifdef USE_PREFETCH
// prefetch instruction(s)
#endif
不过，总的来说，我建议您在完成所有更有成效和明显的事情后，将软件预取作为最后的微优化手段。
关于assembly - 预取指令，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3122915/