Qualcomm Scorpion 双核 ARM NEON 代码有问题?
Posted
技术标签:
【中文标题】Qualcomm Scorpion 双核 ARM NEON 代码有问题?【英文标题】:Problems with Qualcomm Scorpion dual-core ARM NEON code? 【发布时间】:2011-09-29 11:54:34 【问题描述】:我正在为 android 开发一个本地库,我在其中使用 ARM 程序集优化和多线程,以便在双核 ARM 芯片组 MSM8660 上获得最佳性能。在进行一些测量时,我注意到以下几点:
-
具有 NEON 优化的 单线程 库比具有 的 单线程 库更快 >ARMv6 优化(如预期)。
带有 ARMv6 优化的 多线程 库比带有 单线程 库更快 >ARMv6 优化(如预期)。
具有 NEON 优化的 多线程 库比具有 单线程 库的 慢 >NEON 优化(绝对不是预期的!)。
我已经尝试在整个网络上搜索以解释为什么会这样,但到目前为止还没有找到任何解释。似乎所有内核都共享相同的 NEON 管道或类似的东西,但所有示意图似乎都表明每个内核都应该有自己的 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 在多线程代码中获得整体性能提升的唯一方法是,代码具有令人尴尬的并行性,并且线程之间的通信非常少且不频繁。
【讨论】:
以上是关于Qualcomm Scorpion 双核 ARM NEON 代码有问题?的主要内容,如果未能解决你的问题,请参考以下文章