Qualcomm Scorpion 双核 ARM NEON 代码有问题？答案

【问题标题】：Problems with Qualcomm Scorpion dual-core ARM NEON code?Qualcomm Scorpion 双核 ARM NEON 代码有问题？
【发布时间】：2011-09-29 11:54:34
【问题描述】：

我正在为 Android 开发一个本地库，我在其中使用 ARM 程序集优化和多线程，以便在双核 ARM 芯片组 MSM8660 上获得最佳性能。在进行一些测量时，我注意到以下几点：

具有 NEON 优化的 单线程 库比具有 的 单线程 库更快 >ARMv6 优化（如预期）。
带有 ARMv6 优化的 多线程 库比带有 单线程 库更快 >ARMv6 优化（如预期）。
具有 NEON 优化的 多线程 库比具有 单线程 库的慢 >NEON 优化（绝对不是预期的！）。

我已经尝试在整个网络上搜索以解释为什么会这样，但到目前为止还没有找到任何解释。似乎所有内核都共享相同的 NEON 管道或类似的东西，但所有示意图似乎都表明每个内核都应该有自己的 NEON 单元。有谁知道为什么会这样？

【问题讨论】：

标签： performance assembly arm multicore neon

【解决方案1】：

首先，你使用的是什么库？

你是对的，每个内核都有自己的 NEON 单元，但是它是他们自己专有的“VeNum”单元，没有提供太多关于它的信息，它是为 8x50 的基于 Cortex-A8 的 Scorpion 设计的，并且相当比 ARM 自己的 NEON SIMD 实现更好，但是令人欣慰的是，他们 (qcom) 以与基本参考设计兼容的方式设计硬件，因此 cortex-A8 的大多数代码都可以在 Scorpion 上正常工作，尽管有一些由于可能的不同指令时序导致性能下降。

如果您使用“softfp”编译您的程序，您调用的每个使用浮点参数或使用 NEON 单元将寄存器数据从 ARM 内核传输到霓虹灯单元，反之亦然，速度很慢，有时会使内核停顿许多周期，等待管道刷新。

同样对于使用浮点单元的线程程序，内核必须在上下文切换期间保存 FP 寄存器，这样会给线程带来额外的损失，因为我们已经知道将寄存器从 neon 移动到 arm 很慢，并且已知会停止管道。

此外，许多其他因素也可能导致此问题，例如编译器优化不当、缓存未命中、未使用 scorpion 的双重问题功能、错误的指令调度以及重复从一个内核切换到另一个内核。

【讨论】：

【解决方案2】：

这可能是因为缓存未命中。没有更多信息很难判断。

【讨论】：

另一种说法是，瓶颈可能是外部内存带宽——在这种情况下，添加更多内核无济于事。
可以，但是如果只是外存带宽的话，性能至少应该是一样的。当然，添加更多线程会引入更多上下文切换，但我不确定这会对性能产生多大影响。

【解决方案3】：

我的猜测是，这是因为刷新 NEON 管道涉及额外的周期损失。 NEON 管道位于核心的其余部分之后，因此您会看到错过分支的额外循环惩罚等。

如果线程必须经常同步，或者如果你有很多锁，我认为你会看到 NEON 的巨大损失。

您要利用 NEON 在多线程代码中获得整体性能提升的唯一方法是，代码具有令人尴尬的并行性，并且线程之间的通信非常少且不频繁。

【讨论】：