本記事のテーマ
概要
筆者:Antonio D. de Carvalho Jr, Max Rosan,
Andre Bianchi, Marcelo Queiroz
Computer Science Department – University of Sao Paulo
[abstractから引用]
AndroidデバイスでのFFTアルゴリズムのJavaおよびC / C ++実装の実行時間の比較を示しています。マルチスレッドの可能性も考慮して、純粋なJava実装をC / C ++で広く使用されているFFTWライブラリと比較します。35の異なるデバイスでベンチマークし、デバイスモデルとオペレーティングシステムバージョンの特定の組み合わせに関する結果が提示します。また、マルチコアデバイス上のFFTWのシングルスレッドとマルチスレッドの類似点について説明し、開発者が各アプローチをいつ利用できるかを検討します
結果
※本文をDeepLで翻訳
図1から図6は、ブロックサイズの関数として、各デバイス上でFFTアルゴリズムが実行されるのに要した時間を示しています。図1、図2、図3、図4のJava FFTとシングルスレッドFFTWの結果を比較すると、16サンプルよりも大きなブロックでは、シングルスレッドFFTWの方がJava FFTよりも高速であることがわかります。N=16の場合、動的ライブラリをロードする際のオーバーヘッドはCコードの効率では補われないため、シングルスレッドFFTWの結果はJava FFTの結果よりも実際には悪いのですが、より大きなブロックサイズではライブラリは既にロードされています。マルチスレッドFFTWについても同様で、シングルスレッドFFTWの後に実行されるため、ライブラリの初期化のためのオーバーヘッドがありません。
また、図5と図6を見ると、マルチスレッドで使用した場合にFFTWの性能が低下していることがわかります。このように、Androidカーネルはデバイスによって異なるポリシーを持っており、一部のデバイスでは、CPU負荷が高く、持続時間が経過した場合にのみ、スレッドを異なるコアに移動させています。ネイティブの コードがすべての状況で自動的にパフォーマンスの向上を意味するわけではありません。これまでは JNIを使用するとアプリケーションの複雑さが増し、また関連するコストが発生することに気付きました。これは、Java 以外のコードを呼び出すことで、アプリケーションによっては実際に悪化させます (Lin et al. 2011). それにもかかわらず、リアルタイムの 私たちの仕事で評価された信号処理は、以下のようにすべきより多くの機微があることを示しています。処理されるデータ量や起動に関するデバイスの仕様などを考慮に入れておく必要があります。コアとスレッドを移動させています。
www.DeepL.com/Translator(無料版)で翻訳しました。
筆者のまとめ・見解
・サンプルサイズ(N)=16以上の場合はJNIのほうが早い。サンプルサイズが大きいほど結果は顕著である
※ただ、AndroidでNative(C/C++)のライブラリを読み込むのに時間がかかるためJNIのほうが遅くなる場合もある。
・一部のデバイスでは、CPU負荷が高く、持続時間が経過した場合にのみ、スレッドを異なるコアに移動させるため、早くならない場合もある
※Androidデバイスのポリシー(性能、設計)が異なるため
[見解]
2013年の論文なので今のAndroidデバイス&OSでどれほど違いが出るかわかりませんが、機械学習などの重い処理をAndroidに組み込む場合、それぞれのデバイスにあった実装を最適化できる(framework部分を実装できる)技術が必要になるのかな?と思いました。
私は今回、機械学習を用いた音声系のアプリを作成するに当たり、調査しました。
バックグラウンドで収録し続けるアプリなので、Native(C/C++)で実装するようにします。また、時間があればJavaとの比較もしてみようと思います。
参考文献
・FFT benchmark on Android devices: Java versus JNI