Smile Engineering Blog

ジェイエスピーからTipsや技術特集、プロジェクト物語を発信します

信号処理とMIPS・後編

ソフトウェアとMIPS

前編(信号処理とMIPS - Smile Engineering Blog)は、ハードウェアの性能を示すMIPS【Million Instructions Per Second 】について書きましたが、今回はソフトウェアのベンチマークとして書きたいと思います。

MIPS

コンピューターの処理能力を表す単位。コンピューターが1秒間に何百万回命令を実行できるかを示す。

前回も書きましたが、このような説明が多いです。

f:id:jspnet:20191015234008p:plain:left ソフトウェアの開発の要件として、信号処理では演算量(処理量)が必ず問われます。製品開発では、CPUをどれくらいのスペックにするかは言うまでもなく重要で、製品のコンセプトといっても過言でないでしょう。そのコンセプトを実現できるCPUを選定するのですが、売れる商品にするめにはコスト面も重要です。この辺の事情に非常に絡んでくるのがソフトウェアのリソースで、具体的には演算量とメモリサイズになります。

MIPS計算

そのソフトウェアが何命令か、Million Instructions Per Second なので1秒間に何百万命令か?ということですが、デジタル信号処理のソフトウェアを考えたとき、MIPS計算は次の式になります。

MIPS =命令数 × サンプリング周波数 / フレームサイズ × 10^-6

この時のフレームサイズとはサンプル数です。 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、ソフトウェアに求められる演算量は21,333命令以内になります*4

AAC-LC 48kHzの1フレーム(ロングフレーム)に実行できる命令数(1サイクル1命令の場合)
CPU 動作クロック 21.33msのサイクル数 MIPS(1サイクル1命令の場合)
100MHzの場合 21,333 cycles 100MIPS
200MHzの場合 42,666 cycles 200MIPS

アルゴリズムに必要なCPUの性能は?

例えばマルチメディア向けのCPUで、AAC-LCエンコーダのロングフレーム(1024サンプル)の演算量が1,000,000命令だった場合、サンプリング周波数48kHzでは次のMIPSになります。

命令数 MIPS (ロングフレームの場合)
1,000,000 1,000,000 × 48,000 / 1024 * 10^-6 = 47 MIPS

これが意味するところは、実現に向けて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必要か?)というベンチマークにはなります。

*1:ミリ秒

*2:ロングフレームの場合

*3:現実的には、OS(フレームワーク)も、それなりにリソースが必要なので100%はありません

*4:1サイクルで1命令実行される場合

*5:1サイクルで1命令実行される場合

*6:インラインアセンブラや専用命令のintrinsicを含まないもの