我正在尝试优化C代码的关键部分，用于ARM设备和最近发现的NEON中的图像处理。
在阅读了这里和那里的提示后，我得到了非常好的结果，但有一些东西让我无法理解。我发现整体性能在很大程度上取决于内存访问和访问方式。
哪种方法是最简单的(我所说的简单是指，如果可能的话，不必在模拟器或模拟器中运行整个编译的代码，而是可以从小部件中获取并分析它们的东西)，以便了解内存访问是如何"瓶颈"子例程的？
我知道，如果不在特定的硬件和特定的条件下运行它，这是不可能做到的，但目的是有一个"比较"的试错工具来进行实验，即使结果只是近似值。
(类似于这个伟大的循环计数工具)
我想你可能已经回答了自己的问题。内存是一种系统级效应，许多ARM实现者(苹果、三星、高通等)以不同的方式实现系统，结果不同。
然而，当然，你可以为某个系统进行优化，它可能在其他系统上也能很好地工作，所以实际上，这归结为找到一种快速迭代和测试/模拟系统级效果的方法。这确实会变得复杂，所以你可能会花一些钱购买系统级模拟器，比如ARM的RealView中包含的模拟器。或者我可能会推荐一些开源硬件，比如Panda Board，并使用valgrind的缓存研磨。使用panda板上的linux，您可以编写一些脚本来自动化测试。
这可能会很麻烦，但如果ARM优化将成为你职业生涯的一部分，那么软件/硬件投资和时间(与你的薪水相比相对较低)是值得的。
注1：我建议不要使用PLD。这是非常依赖于系统调整的，如果你让它在一个ARM实现上运行良好，它可能会对你的下一代芯片或不同的实现造成伤害。这可能是一个暗示，除了一些基本的数据本地化和订购之外，试图在系统级别进行优化可能不值得你付出努力？(见下面斯蒂芬的评论)。
内存访问是一件简单的无法从"小部件"中建模来生成有意义的指导的事情。缓存层次结构、存储缓冲区、加载未命中队列、缓存策略等……即使是相对简单的处理器也有大量的"状态"隐藏在LSU下面，任何小规模的分析都无法准确捕捉到这种状态。也就是说，有几个获得最佳性能的基本准则：
- 最大化"有用计算"指令与LSU运算的比率
- 对齐您的内存访问(理想情况下为16B)
- 如果需要在对齐装载或对齐存储之间进行选择，请对齐存储
- 尽可能写出完整的缓存行
- PLD主要适用于非统一但在某种程度上仍然可以预测的内存访问模式(这种情况很少见)
- 特别是对于NEON，您应该更喜欢使用
vld1和vst1指令(带有对齐提示)。在大多数微架构上，在大多数情况下，它们是NEON和内存之间移动最快的方式。特别是Eschewv[ld|st][3|4]；这是一个很有吸引力的麻烦，在大多数情况下比在大多数微架构上进行单独的排列要慢