信号処理とMIPS・後編
ソフトウェアとMIPS
前編（信号処理とMIPS - Smile Engineering Blog）は、ハードウェアの性能を示すMIPS【Million Instructions Per Second 】について書きましたが、今回はソフトウェアのベンチマークとして書きたいと思います。
MIPS
コンピューターの処理能力を表す単位。コンピューターが1秒間に何百万回命令を実行できるかを示す。
前回も書きましたが、このような説明が多いです。
ソフトウェアの開発の要件として、信号処理では演算量（処理量）が必ず問われます。製品開発では、CPUをどれくらいのスペックにするかは言うまでもなく重要で、製品のコンセプトといっても過言でないでしょう。そのコンセプトを実現できるCPUを選定するのですが、売れる商品にするめにはコスト面も重要です。この辺の事情に非常に絡んでくるのがソフトウェアのリソースで、具体的には演算量とメモリサイズになります。
MIPS計算
そのソフトウェアが何命令か、Million Instructions Per Second なので1秒間に何百万命令か？ということですが、デジタル信号処理のソフトウェアを考えたとき、MIPS計算は次の式になります。
MIPS =命令数 × サンプリング周波数 / フレームサイズ ×
この時のフレームサイズとはサンプル数です。 FFT（高速フーリエ変換）を例にすると、FFT長（点数）がフレームサイズです。大きければ演算量もメモリも大きくなります。
フレームサイズのサンプル数を時間で表すと
デジタル信号処理のフレームサイズを時間で考えてみると、例えばFFTを使用したアルゴリズムでは、フレームサイズが2のべき乗の場合が多いです。128～1024サンプルをデジタルオーディオのサンプリング周波数に毎に時間（ms*1）で表すと次の表になります。
| フレームサイズ（サンプル数） | 16kHz | 32kHz | 44.1kHz | 48kHz |
|---|---|---|---|---|
| 128 | 8ms | 4ms | 約2.90 ms | 約2.67ms |
| 256 | 16ms | 8ms | 約5.80 ms | 約5.33ms |
| 512 | 32ms | 16ms | 約11.61 ms | 約10.67ms |
| 1024 | 64ms | 32ms | 約23.22 ms | 約21.33ms |
音響処理のフレームサイズについて
ある音声認識エンジンのサンプリング周波数が16kHzの場合、これに向けたノイズキャンセラやエコーキャンセラなどの音響処理や、AIスピーカー向けのキーワードウェイクアップ処理もサンプリング周波は16kHzが都合が良いです。この信号処理のフレームサイズが128サンプルだった場合、1フレームに使える時間は上の表の128サンプル/16kHz = 8ms になります。従って、この信号処理をリアルタイムでやるためには8ms以内に終わらせる必要があります。1024のように大きくするとフレーム時間は1024サンプル/16kHz = 64msで長くなります。処理するサンプル数に比例したものですが、ソフトウェアのオーバーヘッドとが減る分、演算量的には有利になり、バッファリングするサンプル数が多い分、アルゴリズムの性能面でも有利と言えます。ただしフレームサイズが大きいとメモリサイズも大きく、特に遅延が大きくなることでは色々と都合が悪くなることが多いです。
フレームサイズと性能
| フレームサイズ | アルゴリズムの性能 | 演算量 | メモリサイズ | 遅延 |
|---|---|---|---|---|
| 短い場合 | × | × | 〇 | 〇 |
| 長い場合 | 〇 | 〇 | × | × |
音声、音響信号処理のアルゴリズムの性能を良くしたい場合、そのフレームサイズを大きくしたいですが、遅延が大きなると通話目的では話しにくくなります。音声認識向けにはリアルタイムの通話に比べて多少の遅延は許されそうですが、大きくなれば認識エンジンに届くのが遅くなります。
音声コーデックのフレームサイズについて
ちょっと古いですが、私の知っているところの音声コーデックAMR（Adaptive Multi-Rate）のフレームサイズは、Narrow band（8kHz）で160サンプル、Wide Band（16kHz）で320サンプルです。従ってAMRのフレームサイズを示す時間は20msで、通話向けのコーデックとして実現するためには、エンコーダー（送信）とデコーダ（受信）を合わせて20ms以内に処理を行う必要があります。
AMRのフレームサイズ（例）
| AMRの帯域 | フレームサイズ（サンプル数） | 8kHz | 16kHz |
|---|---|---|---|
| Narrow band | 160 | 160 / 8000 = 20ms | - |
| Wide Band | 320 | - | 320 / 16000 = 20ms |
オーディオコーデックのフレームサイズについて
オーディオコーデックの有名なところでMP3やAACがあります。フレームサイズは時間領域から周波数領域に変換するMDCT（Modified Discrete Cosine Transform）というアルゴリズムに関係しています。AAC-LC（Low Complexity）では、ロングフレームとショートフレームに切り替わりますが、ロングフレーム（1024サンプル）は、サンプリング周波数44.1kHzで1024サンプル/44.1kHz = 約23.22 ms、サンプリング周波数48kHzでは1024サンプル/48kHz = 約21.33msになります。 地上波デジタル放送で、音声データの符号化がAAC-LCの場合44.1kHzでは約23.22ms、48kHzでは約21.33ms以内にエンコード処理を終わらせないと間に合わないことになります。
AAC-LCのフレームサイズ
| AAC-LC | フレームサイズ（サンプル数） | 44.1kHz | 48kHz |
|---|---|---|---|
| short | 128 | 128 / 44100 = 約 2.90ms | 128 / 48000 = 2.67ms |
| long | 1024 | 1024 / 44100 = 約23.22ms | 1024 / 48000 = 約 21.33ms |
ソフトウェアに求められるMIPSとは
信号処理には目的に応じたフレームサイズがありますが、このフレーム時間以内にソフトウェアの処理を終わらせられるかが問われます。地上波デジタル放送の放送局側のAAC-LCエンコーダでは、サンプリング周波数48kHzの場合21.33ms*2以内に処理しなければなりません。仮にCPUの動作クロックが100MHzだった場合、リソースを100%使えたとして*3、ソフトウェアに求められる演算量は2,133,333命令以内になります*4。
AAC-LC 48kHzの1フレーム（ロングフレーム）に実行できる命令数（1サイクル1命令の場合）
| CPU 動作クロック | 21.33msのサイクル数 | MIPS（1サイクル1命令の場合） |
|---|---|---|
| 100MHzの場合 | 2,133,333 cycles | 100MIPS |
| 200MHzの場合 | 4,266,666 cycles | 200MIPS |
アルゴリズムに必要なCPUの性能は？
例えばマルチメディア向けのCPUで、AAC-LCエンコーダのロングフレーム（1024サンプル）の演算量が1,000,000命令だった場合、サンプリング周波数48kHzでは次のMIPSになります。
| 命令数 | MIPS （ロングフレームの場合） |
|---|---|
| 1,000,000 | 1,000,000 × 48,000 / 1024 * |
これが意味するところは、実現に向けてCPUの動作クロックが47MHz以上必要になります*5。もし、2,000,000命令だった場合は2倍の94MIPSで、CPUも2倍の動作クロック（94MHz）が必要になります。
製品開発の現場に例えると、ソフトウェアの演算量（見積）によってCPUに求められる性能が決まり、逆にCPUが決まっている場合はその性能の範囲で動作可能なソフトウェアが求められます。信号処理や組込みの分野では、その指標にMIPSが良く使われます（メモリサイズも重要です）。
補足
厳密には、MIPSはCPUの命令セットに依存するもので、同じインストラクション・アーキテクチャを持つCPUの間でしか比較が成立しないものです。ARM社のコアを搭載したCPUと、Intel社のCPUに、CやC++などの同じソースコード*6を実装した場合、コンパイラも違えば命令セットも違うので当然MIPSは変わります。違うCPUで同じソフトウェアを実行した時のMIPS比較は、同じアルゴリズムに何MIPSかかるか？（CPU動作クロックに何MHz必要か？）というベンチマークにはなります。
