コンテンツへスキップ

DSP空挺団

BlackfinとCORTEX-M7のDSP性能が同等ですって?

by

CQ出版のInterface誌2017年4号を読みました。

中森章氏の連載記事『400MHz級制御プロセッサ ARM CORTEX-M7初体験』において、信号処理性能に関して「CORTEX-M7は400MHz動作になって、性能的にBlackfin 7xx(400MHz), Blackfin 5xx(750MHz)と肩を並べることができます」という一節を目にしました。しばし頭の中で疑問符がチカチカと点滅したので調べた次第です。

ARMの大変上手な我田引水をそのまま掲載した、ということのようです。

何故疑問を感じたのか

DSP(プロセッサ)を使っている人はFIRフィルタの性能でプロセッサの能力を見積もります。

この方面の性能は1986年頃を境に、「1Tap/Cycleを実現できて当たり前」というのがDSP分野での風潮となりました。ちなみにこれは命令の速度ではなく「FIRフィルタの性能」ですので、例えばNタップのフィルタを実行する場合の性能を論じる場合に、総サイクル数が「NCycle + 固定オーバーヘッド」になるべきだという話です(もちろん、実際のサイクル数はブロックサイズと関数のオーバーヘッドを巻き込むのでもっとややこしい)。最近ではSIMD化が進んでいますので、1Tap/CycleはローエンドDSPの話であり、ミドルレンジ以上では2Tap/Cycleや4Tap/Cycleが求められます(そしてプログラミングは難しくなる)。

私はCORTEX-M4Fを使ったLPC4300が発表されたあたりからCORTEX-M4Fによる信号処理性能を意識し始め、見積もりを何度かしたことがあります。その際、「DSP性能としては浮動小数点演算で0.1から0.2Taps/Cycle程度」と見積もっていました。ですので200MHzのLPC4300ならば、「うまくすると40MTaps/S。25年前のDSP96000くらいの性能は出るかも知れない」と考え、これは使えそうだとほくほくしていました。

さて、この見積もりでは、CORTEX-M7 @400MHzの性能をCORTEX-M4 @200MHzに対して周波数こみで3倍と考えても、浮動小数点演算で120MTaps/Sです。16bit固定小数点演算だとCORTEX-M7もSIMDが使えますから倍だと考えて240MTaps/S(400MHz時)。これが私の見積もりです。

一方で、Blackfin DSPの固定小数点演算能力は、800MTaps/S(400MHz時)です。到底、同等とは言えないわけです。いや、CORTEX-M7はとてもがんばっていると思いますよ。汎用CPUの性能向上が汎用DSPを追いつめたのは事実ですから。とはいえ、このブログのURLには"bfin"の文字が入っていますし、私のTwitterアカウントには"blackfin"とまで入れています。もう、ほとんど触らなくなったとは言え、「CORTEX-M7はBlackfinに並んだ」と言われると、黙って通り過ぎるわけにもいきません。というわけで、何が起きているのか調べてみました。

もちろん、ほんとうにCORTEX-M7の信号処理性能ががBlackfinに並んだのなら、Blackfinを使わなくなった私にとってはこれ以上無い朗報です。

情報の出所はARMのスライド

中森氏の2017年4号の上記の記事ですが、実際には2016年11号の同連載を参照しているだけです。ですのでバックナンバーを調べてみます。すると、情報の出所としてARM社のChoosing the Best Processor for Your Audio DSP Applicationが挙げられていました。どうやらこのスライドの中の数字を根拠としているようです。

このスライド資料はタイトル通り「オーディオ信号処理プロセッサの選び方」です。ARMが作ったので「ARMの汎用CPUを使うといいよ」と言うためのものです。

中森氏はこのスライドからFFT、FIR、BiQuad(IIR)の性能を引用して、平均すれば400MHz動作時のBlackfin 7xxとCORTEX-M7の信号処理性能が並ぶ、という考えのようです。

ところで、DSPと汎用CPUの比較を理解するためには、DSPのアーキテクチャを理解しておかなければなりません。先に書いたようにDSPでは最低限の要求性能として1Tap/Cycleが求められます。これを実現するために、古典的なDSPアーキテクチャでは

  • ゼロ・オーバーヘッドのループ
  • デュアル・データ・ロード
  • 演算とデータ転送の同時実行
  • サーキュラー・アドレッシング
  • 内蔵SRAM

といった工夫をアーキテクチャに施しました。汎用マイコンであるCORTEX-M4/7はこれらを持っていませんから、別の工夫でにじり寄るしか有りません。

CORTEX-M7ではスーパー・スケーラーによってようやく「演算のとデータの同時実行」できていますが、上のリストのそのほかの項目は無理です。従って、スーパー・スケーラーを活かしたプログラムを書きつつ、あとはスライドのテクニックで数字を寄せていくしかありません。

さて、いよいよ肝心の性能比較の話です。ARMのスライドで性能が並んでいるように見えるのは、次のような事が理由です。

  • FIRフィルタの入力サンプル数が長い場合に限定している
  • 信号処理のワード長が32bit
  • BiQuadはそもそもDSPの性能が出にくい 

これらを順に見ていきましょう。

入力サンプル数

まず、入力サンプル数ですが、FIRフィルタのベンチマークでは256サンプルとなっています。一方、タップ数は5から100までです。つまり、タップ数よりサンプル数が大きくなっています。

ARMがこの構成を選んだのは、汎用CPUにサーキュラ・バッファがないためです。古典的なDSPではFIRフィルタを実装する場合、ディレイラインとしてサーキュラ・バッファを持たせる事で実装します。これにより、内部に保持したディレイラインに1サンプルずつデータを投入しつつ、かつ、バッファ境界の検出をソフトウェアでせずにFIRフィルタを実装できます。一方、汎用CPUにはサーキュラ・バッファがありません。だからといってソフトウェアでこれを実装しようとすると1TAPのMAC毎に境界検出を行うため、演算よりも境界検出のほうが重くなります。

これを解消するため、サーキュラ・バッファを使わないアーキテクチャでは次のような手法のいずれかが採用されます。

  • ディレイラインをTAP数の倍の長さにとって、二つのサーキュラ・バッファに見立て、同じデータを書き込む。この方法ならば、TAP毎の境界検出は不要になる。サンプル毎の境界検出は必要。
  • データのストリーム処理をあきらめ、全てのサンプルを一回の処理でフィルタにかける
  • ブロックサイズ-1だけ余計にもち、ブロック処理後に入力の最後のN-1サンプルを入力バッファの先頭にコピーする

私はコードの汎用性を好むので、大抵はこの三つのうちの最初を選択します。ただし、サンプル毎に余計な判定がはいるため、ピーク性能はわずかに落ちます。2番目は問題外として、ARMがスライドに使ったのは多分3番目です。この方式は条件さえ整えればピーク性能が落ちにくい方法です。で、その条件ですが、入力のブロックサイズがN(TAP数)より十分に大きくなければなりません。そうでなければ、入力サンプルのコピー・オーバーヘッドを隠せないのです。

ARMのスライドを見るとTAP数あたりのサイクル数は10と20の間で少し不可解な動きを見せた後、20と50の間で一旦減少したあと、50と100の間で増加しています。古典的なDSPでサーキュラバッファを組んだ場合、TAP数が大きければ大きいほどループの外側のオーバーヘッドが相対的に小さくなります。しかしCORTEX-M4はそうなっていません。これは先のデータコピーをしているせいでしょう(実際CMSISのFIRフィルタはそうしている)。

サンプルレートが48kSPSの場合、256サンプルは5mS程度です。フィルタのタップ数が100のときにブロックサイズをこれより小さくすると、ARMアーキテクチャではFIRフィルタの性能がだれてきます。これはブロックサイズを充分に大きくしなければならないと言うことで、システムの応答時間に制約を与えます(主観問題ではあるが、大抵のシステムはこの程度なら許容できる)。

なお、この方式はブロックサイズを大きくとるのでメモリサイズの制限が厳しい場合には対応できません。もちろん、汎用マイコンでオーディオ処理をするような条件下では、この程度のメモリの増加は問題にならないでしょう。

信号処理のワード長が32bit

スライドがオーディオ信号処理なのでワード長は32bitです。これは特におかしな事ではありません。もし、音声信号処理と限定するならここは16bitで検討すべきかも知れませんが、オーディオと銘打つなら32bitは妥当だと思われます。

ただ、Blackfinは16bit DSPなんですよ。

Blackfinは16bit DSPとしても、32bit マイコンとしても使えるように設計されたプロセッサです。アナデバもその点を強調し、C言語でプログラムを組める、RTOSが使える、uCLinuxが使えると盛んに宣伝していました。しかしBlackfinは32bit DSPではありません。このミスマッチをスライドに黙って持ち込んだARMのマーケティングの力量は皮肉抜きに賞賛に値します。ただ、技術資料として参考にするときは、ちゃんとそこを見抜かなければだめです。ARMのスライドで評価されているのは32bit マイコンとしてのBlackfinであって、DSPとしてのBlackfinではありません。

Blackfinの基本設計では32bit乗算に3サイクルかかります。BF7xxの新コアでは改善されているようですが、いずれにせよ、もともとは16bit DSPとして設計されたものです。AVアンプのようなヘビーなオーディオ信号処理には今でもアナデバのSHARCやTIのVerociTIが使われています。

ということで、32bit演算の場合、BlackfinはDual Macが活かせません。「DSP性能としてBlackfinと並んだ」という主張には、「Blackfinの良さを活かせない分野では」という但し書きがつきます。

BiQuadはそもそもDSPの性能を出しにくい

中森氏の記事ではFIR, BiQuad(IIR), FFTの性能の平均をとることで「CORTEX-M7はBlackfinに並んだ」と結論づけています。このうち、FIRとFFTはBlackfinが勝っており、BiQuadはBlackfinが劣っています。

これには二つ理由があります。ひとつは上述のように32bit処理なのでそもそもBlackfinはDSPというよりマイコンとしての性能しかでていないという点。もうひとつは、加えてBiQuadはDSPにとっても良さを活かしにくいアルゴリズムだということです。

IIRフィルタにつかわれるBiQuad構成フィルタは、DSPから見たときにFIRフィルタと大きく違う点があります。それはストア頻度が高いことです。古典的なDSPでは積和演算と二つのロード命令を同時実行することで、1Tap/Cycleの処理を実現します。しかしながら、BiQuadはさらにストアまで実現しないといけません(シングル・ステージは除く)。また、サーキュラーバッファを必要としませんので、DSPが持っている専用リソースもあまり役に立ちません。

こういったことから、BiQuadの性能が凡庸であっても不思議ではありません。

それがDSP側で放置されている理由はちゃんとあります。IIRフィルタはFIRフィルタに比べて軽いため、ハードウェアを大して投入する理由にはならないのです。FIRが使われる局面では処理が重く、またFsの2乗で演算負荷が増えていきます。一方、IIRフィルタはそもそもの処理が軽いうえに、Fsが二倍になってもステージを倍にするようなことはしません。

そういうわけで、タップ当たりの性能とステージ当たりの性能から単純に平均をとって「並んだ」とするのは、あまりにも乱暴です。FFTも同じような話ですが、冗長なので説明を省きます。

Audio Weaverのベンチマークへのコメント

インターフェース誌の記事からは離れますが、件のスライドにあるSpeaker Processingのデモについてコメントしておきます。

このデモはスピーカー・イコライザの例を挙げてSHARCで29.86MIPS掛かる処理を、CORTEX-M4で63.16MIPSと評しています。63.16MIPSは倍の時間がかかるということです。しかしCORTEX-M4マイコンのコストを考えれば、比較の必要がないほどCORTEX-M4はコスト・パフォーマンスに優れると言えるでしょう。また、M7はさらによくなるでしょう。

しかし、これは正しい判断でしょうか。32bit SIMD DSPであるSHARCの性能がそこまで「低い」というのも解せない話です。そこで、よくよく掲げられているMIPS測定結果の詳細をみると、手品のタネが分かります。リミッターが必要MIPS数を底上げしているのです。この例ではバスとツイーターにリミッターが入っています。リミッターは非線形処理であり、DSPでも効率的処理はできません。この二つのリミッターはSHARCで15.34MIPSを食っており、実に50%以上です。CORTEX-M4でも22.10MHzを占有していますが、そもそもDSPも苦手な処理なのでSHARCとそれほど差が開いていません。一方、それぞれリミッターを引いた値はSHARCが14.5MIPS、CORTEX-M4は41.0MIPSです。差が三倍近くに開きました。

リミッターはオーディオ・システムに必ず入れるべき信号処理モジュールです。しかし、本来信号処理と人がいうときには勘定には入っていません。このベンチマークでは、非常に軽い信号処理を選んでいるため、リミッターの負荷に必要MIPSが底上げされてDSPとマイコンの差が分かりにくくなっています。

一言添えておくならば、このベンチマークが全く現実離れしているわけではありません。軽いイコライザ程度のシステムは、自動車向けオーディオシステムではよく使われています。ただし、そういうところではSHARCを持ってくるまでもなく、ADIのsigmaDSPやTIのTASといった低価格システムが使われています。

AudioWeaverはBlackfin / SHARC / TI C67xに対応しているそうですが、そういったミドルレンジ以上のDSPが使われるアプリケーションでベンチマークをとると、DSPの良さが分かります。もちろん、ARMの目的はCORTEX-Mxの普及ですので今回のようなベンチマークにしたわけです。ARMが批判されるいわれはありません。

こういうご時世です

長々と書いてきましたが、汎用DSPがどんどん汎用マイコンに駆逐されているのは事実です。

市場の大きな部分で性能はそれほど重視されず、コストと生産性が重視されるようになりました。ムーアの法則とエコシステムとソフトウェアの生産性に後押しされた汎用マイコンが、処理性能を要求しない信号処理分野を侵食していくことは必然です。そして、それによってプログラマの痛みは和らぎます。いい時代です。

しかしながら市場が受け入れたということと、性能が肩を並べたということは違う話です。メーカーが出すベンチマークには必ず背景があり、それを鵜吞みにすればメーカーの都合のいい照明の下で製品を眺めることになります。

DSPは信号処理を低消費電力、低MIPSで実行するために磨き上げられたアーキテクチャを持っており、純粋な性能勝負では汎用CPUと並べることに意味はありません。市場の方向は認めつつも、かつて自分が働いていた汎用DSPというフィールドの事を思い起こして、やや感情的ならがらブログに技術的背景を書き起こしました。

この稿を締めるにあたって、長年のCQ出版社の技術出版物愛読者として、また、この分野で長く生きてきたロートルとして、一言添えておきます。

「DSPなめんな」

「BlackfinとCORTEX-M7のDSP性能が同等ですって?」への3件のフィードバック

  1. デジタル信号処理を考え抜いて作られたアーキテクチャと、高速なMACがついた汎用マイコンとはそもそも同等に比較は難しいと思います。ARMは頑張っているし、それで信号処理は十分というのであれば何も問題はありません。しかし、
    Blackfinのアセンブラニーモニックを見ると、下手ながら信号処理をしているものとしては、まさに芸術作品のような気がして、それを駆使してプログラムを書きたい衝動を抑えられません。
    とくに言われていますように、汎用マイコンにはサキュラアドレッシングがないのは問題として大きいですね。

    返信
  2. まさしくDSPなめんなですよねw
    IIRもサーキュラーを使えばすごく処理は軽くなりますよ。
    Biquadでしたら、通常はdelay lineを2つに集約すると思いますけど、そうではなく愚直に4つのdelay lineを並べる方式にすれば積和系統が1つで済みます。参考まで。

    返信
  3. B767さん
    コメントありがとうございます。以前「やっとこの命令を使った」という話を伺ったと思いますが、考え抜かれた機能を使いこなす、というパズル的な喜びはありますね。私はソフトウェア・パイプラインを組んでいるときが楽しいです。
    サーキュラ・バッファがあるのは便利ですがBfinももう一押しほしかったところです。Quad MACとか、ペナルティ無しの非整列ロードとか。

    Ujiharaさん
    げに、最適化の道は険しく奥深し、ですね。

    返信

コメントする コメントをキャンセル

Wordpress Hashcash needs javascript to work, but your browser has javascript disabled. Your comment will be queued in Akismet!

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください

AltStyle によって変換されたページ (->オリジナル) /