目的
DeepLabのTF-Lite, Edge TPU Modelについて、tflite::Interpreter::SetNumThreadsを変えることによって推論時間がどの程度変化する計測した。
動機
Coral Edge TPUのJuly 2019 UpdatesによってCompilerとAPIがDeepLabモデルをサポート。
Pythonのサンプルが作成できたところで、「TFlite interpreterのスレッド数を増やすことでパフォーマンスが向上する可能性がある」とアドバイスを頂いた。
これは、DeepLabのEdge TPU ModelはサポートしていないOpeがありCPUにオフロードされるため、マルチスレッドで動作させればCPU側にオフロードされたOpeのパフォーマンスが向上するためと思われる。
これは、DeepLabのEdge TPU ModelはサポートしていないOpeがありCPUにオフロードされるため、マルチスレッドで動作させればCPU側にオフロードされたOpeのパフォーマンスが向上するためと思われる。
Edge TPU Compilerで変換。いくつかのOpeがCPU側にオフロードされている |
Edge TPUのPython APIはSetNumThreadsを変更できない(1固定)ため、C++でサンプルを作成した。Edge TPU Model、TF-Lite Modelについて、Jetson Nano、Raspberry Pi 3 B+でスレッド数を変えてモデルの推論時間のベンチマークを計測した。
まとめとかいろいろ
- スレッド数を変更することでパフォーマンス向上が確認できた。
これは、CPU側の処理がマルチスレッドで向上したことによる効果。 - Edge TPU ModelはサポートするOpeが増えた場合、スレッド数の効果は減る(CPU側オフロードが少なくなるから)ので、今後のEdge TPU Compilerのアップデートに期待。
- TF-Lite ModelはCPUで実行するため、マルチスレッドにする効果は大。
- Jetson NanoとRaspberry Pi 3 B+ではJetson Nanoのほうが推論時間が短い。
これは、
・Edge TPU Modelの場合は、USB2.0と3.0の違いが大きい
・TF-Lite Modelの場合は、CPU/Memoryの性能がJetson Nanoの上のため - Raspberry Pi 4はどうなるかな?
- Dev Boardは手持ちにないので未計測。
ベンチマーク方法など
使用したベンチマーク用のコードはGitHubにアップ。
- 読み込んだ画像に対して推論を20回行った平均で算出。
- スレッド数は1〜4(コア数分)まで変化させて計測。
- 入力(1, 513, 513, 3)、出力(1, 513, 513, 1)のリサイズ、セグメンテーションマップの生成は含まない。
- 使用したモデルは
・TF-Lite ModelはQuantized modelのdeeplabのモデルを使用。
・Edge TPU ModelはQuantized modelから生成(ここにモデルをアップ)。 - Edge TPU Compiler、APIはJuly 2019 Updatesを使用。
- tflite::Interpreter::SetNumThreadsの指定はここを参照。
ベンチマーク結果
DeepLabのモデルとデバイスごとの推論時間(単位:ms)
その他
- 公式のベンチマークによると、DevBoardでは推論時間は156msとある。
これは、Jetson Nanoでスレッド数に4を指定した場合とほぼ同等である。
公式ではDeepLabのモデル、ベンチマークプログラムとも公開されていない。
公開されてから比較が必要かもしれない。 - Edge TPU Compilerのバージョンがアップされ、サポートOpeが増えた場合、このベンチマークは意味がなくなる。注意が必要。
感謝
- @Mangobearさん
「TFlite interpreterのスレッド数を増やすことでパフォーマンスが向上する可能性がある」とアドバイスいただきました。今回のベンチマークを行うきっかけをいただきました。 - iwatakeさん
C++コードを書く際に「Google Coral Edge TPU with C++ on Jetson Nano」を参考にさせていただきました。
ありがとうございます。
0 件のコメント:
コメントを投稿