立ちふさがる課題
これらのプロセッサアーキテクチャをチップ内に混在させなくてはならない設計者にとっては依然として課題が残っている。混在処理設計をサポートするツールの課題は、プログラミングモデルをどのように維持し、設計者にどのようにして並列処理を活用させるかということだ。混在処理設計を採用し、それをサポートするツールを使用する場合には、開発チームの高い生産性を維持することが重要である。設計チームが、特定のプロセッサ・アーキテクチャに対応した開発ツールに関する知識が乏しいことを理由に、そのアーキテクチャを候補から外すことは珍しいことではない。
一企業の既存のコードには、膨大な量のエンジニアリングと設計に関する教訓が詰まっている。設計チームがアプリケーションコードを一から書き直したいと思わないかぎり、利用可能な並列処理を活かすためには従来のコードを再分割する努力が必要である。しかし、努力してもクリーンかつ自然に分割できるとは限らない。再分割がうまくいかないと、データ構造の実装もうまくいかない。データ構造が自然かつ明瞭にアプリケーション要件を表していなければ、面倒なコーディングとデバッグの作業が発生する。
混在処理設計を採用した上で既存のコードを使用する開発者の生産性を維持する鍵は、より成熟したコンパイラ制御技術にある。コンパイラによってシステムリソースのすべてを可視化できないかぎり、リソースの割り当てと利用については保守的な仮定を立てるしかない。コンパイラのパフォーマンスを向上させ、従来のコードから最善の結果を得られるよう、コンパイラに使用される規則と仮定を開発者が自在に設定できる新しいスキルがそのうち出現するだろう。
このトレンドは、特定の垂直市場向けデバイスを提供し続けているプロセッササプライヤにも見られる。これらのデバイスにも、ターゲットアプリケーションに適したプロセッサリソース群、ハードウエアアクセラレータ、プログラマブル・ロジックが組み込まれるようになるだろうが、ターゲットになるのは量産アプリケーションのみだろう。
その他のアプリケーションでは、設計者は自分で処理オプションを組み合わせる必要がある。分散マルチプロセッサトポロジを使用することで処理パフォーマンスを向上できることが明らかになりつつある。今日のツールベンダーの課題は、タスクをうまくカプセル化して、混在プロセッサコンフィギュレーションのサポートを実現する方法を生み出すことである。
プロセッサ・アーキテクチャの特長
アーキテクチャにはそれぞれ得意とする処理の特長が異なる（図A）。すべての対応領域に他の対応領域と重なり合う部分を持たせることで、考え得る処理シナリオのすべてをカバーしている。したがって、カバーされていない領域があれば、そこには他の特定のアーキテクチャが存在すると想定できる。処理要件が厳しく、演算負荷の大きいアプリケーションが増えるにしたがい、統合され、混在する処理トポロジがあちこちに見られるようになるだろう。
ソフトウエアの複雑さをどのように評価するかについて、本記事では処理に関する4つの評価基準を取り上げている。計算負荷は、アプリケーションが一定時間内で実行しなくてはならない反復計算の数を評価するものだ。この方法では、計算の制御処理を見ることによって、マルチステートアルゴリズムが純粋にハードウエア実装するには大きすぎるかどうかを把握できる。本記事では、これら2つの基準をプロセッサの特長をマッピングする主軸として使用している。
アプリケーション処理は計算負荷に相当する。しかし、コードが一貫して予想どおりに反復されることはない。アプリケーション処理は並列実装に向かないコードである。最後は、システムの応答要件を基準にする方法である。中でも最も関係があるのはリアルタイムシステムの応答要件である。この方法は、たいていはオペレーティングシステムまたはキャッシュの使用が原因となる、プログラムの実行タイミングの不確実さが、どのようなときにアプリケーションの応答要件を超えるのかを把握するのに役立つ。また、マイクロコントローラが適する主なアプリケーション要件を特定することもできる。
Copyright © ITmedia, Inc. All Rights Reserved.