我对有关使用 GCC 和 EABI 的 ARM-CPU 目标的特殊 C 编程技术的任何建议感兴趣。我的应用程序包含对大型数据数组的浮点密集型计算。主要目标是获得最快的可执行文件。大多数情况下，我使用 codesourcery 和 android-ndk 的 arm-eabi-gcc 版本。我也不想使用 neon-intrinsics 或对 C 代码进行任何更改，这与其他架构的其他编译器不兼容（例如 IA32 的英特尔编译器）。
【问题讨论】：
标签： android c gcc arm signal-processing
由于大多数 ARM 目标没有 FPU，如果您想要“最快的可执行文件”，您应该考虑使用定点库。这篇 Dobb 博士的文章：Optimizing Math-Intensive Applications with Fixed-Point Arithmetic 对 CORDIC 算法有很好的解释，并为文章中讨论的库提供了完整的源代码。这篇文章正是关于在没有 FPU 的 ARM 设备上加速数学密集型代码。报告的结果通常是浮点实现的 4 倍加速，考虑到不使用矢量化的 VFP（编译器不太可能支持，除非通过库代码）提供 5 倍的加速，这对于软件实现来说非常好。
注意：我使用过这个库，发现 log() 函数有错误。通过在 log_two_power_n_reversed[] 数组初始化程序的末尾添加 0x0LL 来纠正此问题。我已经与作者确认了这一更正。文中代码链接坏了，找到：ftp://ftp.drdobbs.com/sourcecode/ddj/2008/0804.zip
[编辑] 糟糕，抱歉，文章和代码讨论了 C++ 实现，广泛使用运算符和函数重载以尽可能透明地使用 fixed 类型。使用 C++ 编译可能是一个很好的理由，但不是您所要求的。
【讨论】：
如果您想保持可移植性，我的建议是“不要使用浮点”。大多数 ARM 芯片没有 FPU，必须在软件中模拟操作。
一般来说，基准测试、更改和基准测试。任何没有彻底的前后性能测量的性能优化都是徒劳的。
【讨论】：
vcmpe/vmrs/b{cond} 序列导致很长的 CPU 停顿。另请参阅this ARM documentation 的建议：“与条件执行相比，使用高级 SIMD 值选择操作比使用等效 VFP 更有效。”.
要在没有 FPU 的 CPU 上最大化性能，还应该选择“软浮点”而不是“硬浮点”。这样，您的可执行文件将与浮点库链接，而不是依赖内核捕获非法指令并在内核中模拟它们（由于涉及上下文切换，这需要更多时间）。
当然，如果你有一个带有硬件浮点单元的CPU，你应该使用硬浮点来利用它。
幸运的是，EABI 允许两种类型的可执行文件和库和平共存。
【讨论】：
唉，为了在当前用于智能手机的所有 ARM 处理器上获得最佳数字运算性能，最好的方法可能是为每个 ARM 架构做一些完全不同的事情：缩放整数运算或用于无 fpu 芯片的较慢的软浮点，具有流水线 VFP 硬件的芯片的可重叠浮点，以及支持 NEON 的芯片的并行非便携式 NEON 内在函数。您可能必须编写所有这些代码，并在检测到 CPU 架构后使用运行时计算例程选择。
【讨论】：