加快浮点运算(Android ARMv6)

Nic*_*ick 4 floating-point optimization android arm armv6

我正在使用本机代码在Android中进行一些图像压缩.由于各种原因,我不能使用预先构建的库.

我使用android-ndk-profiler分析了我的代码,发现瓶颈是 - 令人惊讶的 - 浮点运算!这是配置文件输出:

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  ms/call  ms/call  name    
 40.37      0.44     0.44                             __addsf3
 11.93      0.57     0.13     7200     0.02     0.03  EncodeBlock
  6.42      0.64     0.07   535001     0.00     0.00  BitsOut
  6.42      0.71     0.07                             __aeabi_fdiv
  6.42      0.78     0.07                             __gnu_mcount_nc
  5.50      0.84     0.06                             __aeabi_fmul
  5.50      0.90     0.06                             __floatdisf
  ...
Run Code Online (Sandbox Code Playgroud)

我用Google搜索__addsf3,显然它是一个软件浮点运算.呸.我对ARMv6架构核心进行了更多的研究,除非我遗漏了什么,否则它没有硬件浮点支持.那么我能在这里做些什么来加快速度呢?固定点?我知道通常用整数完成,但我不确定如何转换我的代码来做到这一点.是否有我可以设置的编译器标志,所以它会这样做?欢迎其他建议.

650*_*502 8

当然你只能用整数运算做任何事情(毕竟你正是你现在正在做的事情)但是如果它可以更快地完成或者不是真的取决于你想要做什么.

浮点数是一种通用的解决方案,你可以在大多数情况下应用它而忘记它,但是你的问题确实需要从极小到极大的数字以及52位的尾数准确度.假设您的计算是关于具有双精度浮点数的图形,您可以从远小于亚原子尺度到远远超过宇宙尺寸...是否真的需要该范围?提供的准确性当然取决于FP的规模,但您真正需要的准确度是多少?

您的"内循环"中使用的数字是多少?不知道如果计算可以更快或更快地进行,则很难说.几乎可以肯定它可以更快(FP是一种通用的盲解决方案)但你可能希望获得的收益程度变化很大.我不知道具体的实现,但我希望它具有合理的效率(对于通用情况).

您应该瞄准更高的逻辑优化级别.

对于基于DCT或小波变换的图像(de)压缩,我认为确实不需要浮点运算:你可以只考虑你的数字的精确尺度并使用整数运算.此外,由于能够产生近似结果,您可能还具有额外的自由度.