新人技術者のためのロジカル・シンキング入門(8) ―― CPUの演算量をひたすら削る

冴木 元

tag: 組み込み

技術解説 2008年10月21日

【1】古くて新しい「最適化」

 さて,ここに挙げた例は多少誇張されており,実際にここまで切羽詰まってから性能(処理速度とメモリ使用量)の問題がクローズアップされることはまれであると思われます.とはいうものの,組み込みシステムの開発において,性能がしばしば問題となることは事実です.多少まし(?)な開発であっても,開発が終盤にさしかかってから処理量をくっている「犯人探し」が始まるケースなら,枚挙にいとまがないように思います.

 性能問題,裏を返せば「いかにして最適化するか」という,古くて新しい問題が今回のテーマです.

● 性能は「当たり前品質」

 最初に注意しなければならないのは,組み込みシステムにおける「性能」とは,多くの場合,備えていて当然(製品が備えるべき最低限の品質である)と認識される性質のものであるということです.例えば,性能を満たしていれば1,000万円で売れるモジュールも,性能が不十分なら500万円にもなりません.それどころか,0円になりかねません(図1).一般的な用語で言い換えると,性能は「魅力的品質」ではなく,「当たり前品質」であるといえます注2

注2;JIS Z9901-1991の定義によると,「当たり前品質」とは,製品が当然備えるべき最低限の品質であり,不十分であるとユーザに不満足感を与える.一方,「魅力的品質」とは,ユーザが製品自体に魅力を感じ満足感を持つ品質を指す.

zu01_01.gif
図1 組み込みシステムは性能が万全で当たり前
テレビ電話の組み込みソフトウェアの例.使用するCPUの動作周波数が300MHz,メモリ・サイズが1.5Kバイトだとしたら,ソフトウェアをすべて集めたときにこの範囲に収まるように作らなければならない.これが出来なければ動かないので,商品価値はゼロ.

 ソフトウェアは本来,CPUの動作周波数とメモリの大きさの制約を受けるため,処理速度とメモリ使用量にはおのずから限界があります.このこと自体はパソコンで動くアプリケーション・ソフトウェアなどでも変わりはないのですが,パソコンのCPUやメモリは大抵の場合十分にあるので,実際の開発でシビアに性能が問われることはそれほど多くないように思います.

 しかし,組み込みソフトウェアの開発では,ハードウェア・リソースがぎりぎりであることがほとんどです.そのため,組み込みソフトウェア・モジュールの開発においては,開発の最初から性能問題を意識する必要があります.最初に全体の工程を考える際に,最適化のフェーズを設けるのはもちろんのこと,後工程での最適化がスムーズに進むように考慮して設計しておく必要があります.

● 最適化は正しく動くのが大前提

 もう一つ注意が必要なのは,最適化というのはあくまでも「仕様通り正しく動くモジュールがある」ことが前提となる,ということです(図2).つまり,最適化をかける以前に,仕様通り動くモジュールが出来上がっている必要があります.そして,最適化した後にも,この品質が損なわれるようなことがあってはなりません.たとえ処理速度が上がっても,その代わりに仕様通り動かなくなってしまったのであれば,最適化とは呼べません(単にバグを埋め込んだことになってしまう).

zu02_01.gif

図2 最適化の流れ
最適化するには,その前提として,「正しく動く組み込みモジュール」が存在しなければならない.そして最適化段階のデバッグでは,「正しく動くか」に加えて,「速く小さく作れたか」を考える必要がある.

 従って,最適化のためには,優れた最適化設計の考え方が必要なのはもちろんのこと,品質劣化を防ぐための適切なテスト・ケースが必要となります.

● ボトルネックはCPU? それともメモリ?

 それでは,ここから最適化設計の考え方を解説していきます.「最適化」という言葉は,処理速度の向上とメモリ使用量の削減の両方を意味するものですが,ここでは主として,処理速度の向上に重点を置いて解説します.

 最適化設計で重要となるのは,ボトルネックとなるものが何かをあらかじめ見抜いておいて,そのために必要な対策をあらかじめ考えておくことです.ボトルネックとなりうるものは,大きく分けると,次の二つのいずれかです.

  1. CPUの演算量
  2. メモリのアクセス速度

 1)は演算処理自体が多いために,効率の悪い命令で実装していると,処理速度が遅くなってしまうケースです.具体的には,音声系のコーデック処理などで問題となります.これらは,積和演算のような重い処理でループが組まれているため,効率の悪い命令で実装してしまうと,無駄な処理量がループの回数分だけかさんでしまうことになります(図3)

zu03_01.gif
図3 重い演算処理の実装方法がポイント
オーディオ系のコーデックなどは,処理量を費やす演算部分をいかにして最適化するかがポイントとなる.例えば,積和演算がそれに当たるわけだが,開発に用いるCPUのアーキテクチャに照らして,どのように実装すると高速になるかを理解する.

 逆に,2)のようにメモリのアクセス速度がボトルネックになるのは,演算処理自体の重さよりも,扱うデータ量が大きすぎてメモリ上に配置できない場合です.これは,画像処理などでよくあるケースです.

 この連載で何度か述べてきたことですが,CPUコア内部のメモリ(内部メモリ)はアクセス速度が速いのですが,大きさが限られています.そのため,あらゆるデータをそこに配置できるわけではありません.画像処理のように大きなデータを扱う場合は,それらをすべて内部メモリに配置できるわけではないので,外部メモリに配置することになります.しかし,外部メモリは内部メモリに比べて圧倒的にアクセス速度が遅いため,これをいかにして回避するのかが問題となるのです.

 今回は,1)のケース,すなわちCPUの演算量を削減することによって最適化を図るケースについて,具体的な方針を述べていくことにします.

組み込みキャッチアップ

お知らせ 一覧を見る

電子書籍の最新刊! FPGAマガジン No.12『ARMコアFPGA×Linux初体験』好評発売中

FPGAマガジン No.11『性能UP! アルゴリズム×手仕上げHDL』好評発売中! PDF版もあります

PICK UP用語

EV(電気自動車)

関連記事

EnOcean

関連記事

Android

関連記事

ニュース 一覧を見る
Tech Villageブログ

渡辺のぼるのロボコン・プロモータ日記

2年ぶりのブログ更新w

2016年10月 9日

Hamana Project

Hamana-8最終打ち上げ報告(その2)

2012年6月26日