如何解决Neon / RPi上的64位DSP过滤性能优化
我在Analog Devices Sharc DSP处理器上有一个32位C ++ DSP音频处理项目，需要将其移至64位处理，这已经有一段时间了，可用于ARM AArch64的嵌入式用例。
我正在考虑两种选择：
除64位精度外，我还进行了大量cpu密集型处理。我还需要获得更多的处理能力，因为当前Sharc性能也是一个瓶颈。 IIR和FIR功能应提供基于块的64位实时信号处理。
我的目标平台是RaspBerry Pi，可能是3B +。4。例如，我提供了我需要的功能。在CMSIS库中以arm_biquad_cascade_df2T_f64()的形式出现（它实际上与补充的init函数一起使用，该函数实现以基于块的方式处理数据所需的状态数组）。而且库函数似乎可以与64位一起使用。但是我怀疑它们是否适合AArch64，并针对AArch64进行了优化，因为通常CMSIS也被标记为32位Ne10。
或者仅由编译器优化和使用Neon就足够了吗？
解决方法
如果您有选择，那么就性能而言，您肯定会选择AArch64而非32位Neon实现。 AArch64具有更多/更广泛的矢量寄存器。由于AArch64放弃了普遍存在的32位指令集的条件执行，CPU会从乱序执行中获得更多收益，这很容易通过条件标志引起指令之间的额外依赖。
我最近从一个特定的优化任务中得出的个人结论：
- 与gcc相比，clang的自动矢量化效果更好
- clang 10的自动矢量化效果优于clang 8
- clang对特定Cortex内核的调优令人印象深刻
- 有用的clang标志：
-Rpass=loop-vectorize -Rpass-missed=loop-vectorize -Rpass-analysis=loop-vectorize - 两个编译器都未能克服AArch64矢量收集负载的不足
- 手动矢量化的代码仍然比自动矢量化性能高2倍
- 使用索引不足的文档阻碍了使用ARM向量内在函数进行编程，并且ARM将所有向量指令从ARMv7重命名为AArch64
- 使用llvm-mca（https://llvm.org/docs/CommandGuide/llvm-mca.html），非常有用
请记住，这些经验不应该被宽泛地概括，这是一项特定的任务。
通过手动优化的实现方式可获得多少性能取决于自动矢量化程序是否可以使用特定的纯C代码。
我从一个普通的C实现开始，将其自动矢量化，研究llvm-mca输出，发现自动矢量化代码的弱点，然后从那里开始工作。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。