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

【4】最適化にはCPUアーキテクチャの理解が必要

　ここまで，コンパイル結果の無駄を見抜いて改造する観点からアセンブリ言語のコーディングを解説してきました．

　しかし，「コンパイル結果の流用」というアプローチのみでは限界もあります．アセンブリ言語と高級言語ではデータ構造の持ち方が根本的に異なるため，演算によっては，流用がきかないものもあるからです．例えば，信号処理のフィルタ演算などがそれに当たります．そのような場合には，関数をまるごと一つアセンブリ言語でコーディングする必要が生じます．

　最適なアセンブル・コードを書くには，なによりもまず，CPUアーキテクチャの特徴をよく理解する必要があります．そして，自分が実装しようとしている演算を高速化できるような命令がCPUに用意されていないか，CPUのマニュアルをよく読んで工夫する必要があります．

　組み込みシステム用に開発されたCPUアーキテクチャは，処理速度を高めるためにいろいろな工夫を施してあります．その特徴を把握することが大切です．

　演算効率を高めるためにCPUアーキテクチャが採る方法は，大きく分けて次の二つがあります（実際には，これらの組み合わせでCPUは実装されている）．

1） ソフトウェア・パイプライン

　ソフトウェア・パイプラインとは，一連のCPUの命令を並列化して，1サイクルにいくつもの命令を実行できるようにすることです．ロード命令→乗算命令→加算命令→ストア命令という命令を繰り返すのであれば，命令を一つ一つ処理するのではなく，個々の命令を並列化してしまって1サイクルで複数の演算をこなしてしまえば，処理速度は向上することになります（図12）．従って，コンパイラがもし命令のソフトウェア・パイプライン化を十分に行っていないのであれば，プログラマがアセンブル・コードを書き換える必要があります．

図12　ソフトウェア・パイプラインの例
LOAD，ADD，MPY，STOREと一つ一つ実行するよりも，並列化して次々と実行した方が処理速度は向上する．1サイクルに複数の命令を実行できる機構を大抵のCPUは持っているので，いかにして多くの命令をソフトウェアでパイプライン化できるかが処理速度向上のポイントとなる．

2） 専用命令の実装

　専用命令の実装とは，一つの演算器で複数の命令を同時に処理することができるような回路をCPUが内蔵する場合を指します．例えば，積和算を同時に二つ実行できるDual Mac命令がCPUに実装されている場合などがそれに当たります（図13）．

図13　専用命令の例
一つの演算回路が二つの積和算を一度に行えるのがDual Mac命令である．このような専用命令は，使えるレジスタやメモリに制限があることが多いので，制約を満たすようにアセンブリ言語を書くこと．また，そもそもこの命令をコンパイラが生成してくれないこともしばしばある．

　注意しなければいけないのは，このような専用命令がCPUのアーキテクチャには用意されていても，コンパイラはそれを生成してくれないことがむしろ多いということです．その場合は，コンパイラの生成コードとC言語の実装をよく見比べて，効率的な命令をコンパイラが期待通り生成してくれているかをチェックする必要があります．

　そして，「自分ならこう書く」というコードをコンパイラが生成してくれていないのであれば，プログラマがアセンブリ言語を自分で書く必要があるということです．

● 最適化ノウハウの汎用性について

　CPUの命令を駆使して最適化を行う知識は，専門技術性が高く，個々のCPUに固有のものと従来は考えられてきました．このこと自体は否定の余地がないようにも思えます．しかし，組み込みシステムの開発環境において，技術者たちが培ってきた技量が応用のきかないその場限りのものだ，と考えるのはいかにももったいない気がします．なぜなら，変化の激しい組み込みシステムの開発の現場では，次から次へと新しいアーキテクチャに対応するように迫られることが多いからです．

　一つの例として，自動車に組み込まれる車載システムについて考えてみましょう．自動車は，カー・ステレオやカー・ナビゲーションのような運転者の目に見えるものから，エンジン制御のような目に見えないものも含めて，1台の車にさまざまなCPUが積み込まれています．現在では，普通の車でも60個程度，多いものだと100個ものCPUが組み込まれていると言われます．その中で最適化がシビアに問われるものがどの程度あるのかは筆者には分かりませんが，それぞれがエキスパートのみが知る世界で，相互に連絡があり得ないとしたら，寂しい限りのような気がします．

　技術者が自分の専門性を深めることは非常に重要です．しかし同時に，自分の技術がどの程度の汎用性を持ちえるのかを考えることも時には必要だと思います．誇り高きベテラン・エンジニアでも，自分が長年親しんできたアーキテクチャが，気が付いたらお払い箱になっていることもあるかもしれません．そうでなくても，やがては管理者として後進の指導に当たらなければならないときに，自分の経験したことだけに閉じた昔話しかできないのだとしたら，開発現場の足をひっぱることになるでしょう．

　最適化のように，一見応用のきかない実装依存の知識であっても，汎用化させるとしたらどのようなことが考えられるのかを問うてみるのは，重要であるように思います．

さえき・はじめ
＜筆者プロフィール＞
冴木 元．システム・エンジニア．「ゴルフのスイングをしながらしゃべるサラリーマン」というのは，ある種典型的な行動パターンと思われるのだが，なぜか筆者の周囲ではお目にかかることが少ない．ゴルフをしないのは単に金がもったいないからか？ 世の中には「ゴルフをするところを見れば人間が分かる」と言う人すらいるらしいのだが，いったい彼らは，何を見てそう言っているのだろう？