ゼファーネットのロゴ

生成的データ インテリジェンス

半導体

システムレベルでのエネルギーの最適化

プラトン再発行
プラトン再発行

日付：

閲覧数： 49

電力は普遍的な懸念事項であり、システム全体を考慮せずにシステムのエネルギー消費を最適化することは不可能です。ハードウェア実装の最適化においては大きな進歩が見られましたが、それだけではもはや十分ではありません。システム全体を最適化する必要があります。

これには広範囲にわたる影響があり、その一部はドメイン固有のコンピューティングへの道を推進しています。シフトレフトも役割を果たしますが、より重要なのは、定義されたタスクの総エネルギー消費量に関与するすべての関係者が、その目標を達成するために協力する必要があることを意味します。

エネルギーは急速に第一級の考慮事項になりつつあります。 「すべてのコンピューティング領域にわたってエネルギー効率が重大な懸念事項となるため、アーキテクトはハードウェア設計とソフトウェア設計の両方でアルゴリズムのエネルギーコストを考慮するよう求められることがよくあります」と、同社の製品管理および戦略的マーケティング担当シニアディレクターであるギヨーム・ボイエ氏は述べています。 アルテリス。 「焦点は、計算効率 (速度、スループット、レイテンシ) のみを最適化することから、エネルギー効率 (操作あたりのジュール) も最適化することに移行しています。これには、メモリ アクセスの数、計算の並列性、特定のタスクに対してよりエネルギー効率の高い計算を提供できる特殊なハードウェア アクセラレータの利用などの要素を考慮する必要があります。」

これにより、焦点はハードウェアの実装からハードウェアとソフトウェアの両方のアーキテクチャ分析に移ります。 「設計フローの後半段階では、最適化の機会が減少します」と、EDA グループの製品管理ディレクターである William Ruby 氏は言います。 シノプシス。 「自動最適化の機会は増えるかもしれませんが、改善率は小さくなるという制約があります。潜在的な節約の曲線 (図 1 を参照) を考慮すると、アーキテクチャから承認までの曲線は滑らかではありません。合成には変曲点があります。設計が実装にマッピングされる前は、より多くの自由度がありますが、この変曲点を過ぎると、状況は大幅に低下します。」


図 1: 設計段階での省電力の機会。出典: シノプシス

大きな障壁は、変曲点の前では電力がアクティビティに依存するようになるため、自動最適化がはるかに困難になることです。 「RTL 開発中に、動的ベクトル駆動チェックを使用して無駄を発見し、ロジックの再構築、クロック ゲーティング、オペレーター ゲーティング、その他の手法を実行して無駄を削減できます」と、 シーメンスEDA。 「電力はユースケースに依存するものであり、考えられるすべてのシナリオが確実にカバーされるように、実際のソフトウェア主導のワークロードを使用してプロファイリングする必要があることを理解することも重要です。これは、完全な SoC のコンテキストで特に当てはまり、電力エンベロープは、IP レベルでの合成ベクトル駆動解析で示されるものとは完全に異なる可能性があります。」

「事前の計画、プロファイリング、最適化がさらに必要になります」と、シノプシスの仮想プロトタイピング担当主任エンジニアのティム・コーゲル氏は言います。

コーゲル氏は、対処する必要があるさまざまなレベルを指摘しました。

  • マクロ アーキテクチャ レベルでは、大きなトレードオフの分析と専用の処理要素の選択を行います。
  • マイクロアーキテクチャ レベルで、ターゲット アプリケーションの命令セットと実行ユニットを最適化します。
  • アルゴリズム レベルでは、計算効率とメモリ アクセスのためのアルゴリズムの選択と最適化、および
  • ソフトウェア レベルでは、電力とエネルギーに関してソフトウェアを最適化する方法について開発者にフィードバックを提供します。

「これには、ハードウェアとソフトウェアの実装を最適化できるデータを生成するための仮想プロトタイピングとソフトウェア開発のための電力とエネルギーを意識したツールが必要になります」と同氏は述べました。

ソフトウェアマッピング
ソフトウェアに何を含めるべきかを決定するのは初期の作業です。 「CPU の負荷を軽減する DSP コアが必要ですか?」シノプシスのルビーは尋ねる。 「それは消費電力にどのような影響を与えるのでしょうか?ハードウェア アクセラレータを実装したいですか? それともこれらすべての機能をソフトウェアで実行したいですか? CPU 上で実行されるソフトウェアのエネルギーコストはゼロではありません。」

システムがソフトウェアによって定義されるようになるにつれて、エネルギーについての検討を開始する必要があります。 「ソフトウェアは、エネルギーの節約とパフォーマンスの向上に関して重要な要素です」と、同社のシニア プリンシパル CPU アーキテクトである Vincent Risson 氏は述べています。 腕。 「コンピューティング集約型のアプリケーションは、多くの場合、アプリケーションの最適化によって大きな恩恵を受けます。これは、高度に調整されたライブラリという点で静的であることも、最適な処理エンジンを対象としたコンピューティングを可能にする動的フレームワークであることも可能です。たとえば、モバイル デバイスは、共通の ISA と構成に準拠しながら、アプリケーション プロセッサにさまざまな計算パフォーマンスを提供する CPU システム アーキテクチャを標準化しています。これにより、アプリケーションを効率的に最適なプロセッサに動的に移行できるようになります。ソフトウェアと異種ハードウェアの両方の組み合わせによって提供される内省と多用途性のためのメカニズムは、将来的に効率を向上させる機会を提供するでしょう。」

多くの場合、ソフトウェアが実行できるプロセッサのクラスは複数あります。 「私たちは、発生しているワークロードのタイプに基づいて、特定のアプリケーションをどこで実行するかを選択できます」と、Intel フェローでクライアント SoC アーキテクチャのデザイン エンジニアリング グループ CTO を務める Jeff Wilcox 氏は述べています。 「小さなコアのニーズを超えた場合は、より大きなコアを起動することができます。最も電力効率が良いためにどこで実行すべきかを判断するために、テレメトリとワークロードの特性評価が行われます。現在私たちが目にしているワークロードの多くはこれまでとは異なっています。同じワークロードを処理している対称エージェントであっても、相互に依存関係があります。 GPU、NPU、IPU が利用可能で、これらのタイプのワークロードが CPU と連携する非対称エージェントを必要とするワークロードがますます増えています。それを最適化するのは非常に難しいことです。私たちは、パフォーマンスと電力の課題を理解するためのフックを手に入れるところまでは到達しましたが、それを完全に消化して最適化する方法を実際に理解するためのツールを構築している段階です。」

ここでの問題は、ワークロードのアーキテクチャがハードウェアのアーキテクチャに依存する可能性があることです。 「AI の分野では多くの進歩があり、重要なのはモデルのサイズだけではありません」と Untether AI のハードウェア担当バイスプレジデントである Renxin Xia 氏は述べています。 「モデルがどのように構築されるか、またエネルギー効率の高い方法で構築されているかどうかも同様に重要です。アーキテクチャに依存するため、これに答えるのはさらに困難です。 GPU 上で実行されるアルゴリズムのエネルギー コストは、コンピューティング アーキテクチャのメモリ上で実行されるそのアルゴリズムのエネルギー コストとは大きく異なる可能性があります。」

ソフトウェアに焦点を当てる
一般的なコンセンサスは、ハードウェアとソフトウェアの連携がさらに強化されなければ、これは不可能だということです。 「これらのステップ関数を改善するには、ハードウェアとソフトウェアの共同開発が必要です」と、インテルのデータセンター部門の上級研究員であるサイレシュ・コッタパリ氏は述べています。 「ハードウェアで透過的に実行しようとするだけでは限界に達しています。 AI で何が起こっているかを見てください。もしハードウェアが唯一の要素であれば、私たちが見ているような大きな進歩は見られなかったでしょう。その多くはアルゴリズムの改善です。ソフトウェア アルゴリズムを使用すると、パスの長さを短縮すると、より少ない命令数とソフトウェアの作業量の削減で同じ結果を達成できます。それが明確になると、それらのアルゴリズムには新しい最適な命令セットや新しいマイクロアーキテクチャがあることがわかり、それをハードウェアでさらに最適化できることがあります。」

ソフトウェア開発フローを大きく変える必要があります。 「これまで、アーキテクチャとソフトウェア フローは生産性を考慮して最適化されていました。つまり、最速かつ安価なソフトウェア ツールを使用して、高級言語でプログラムされた汎用プロセッサが使用されていました」とシノプシスのコーゲル氏は言います。 「一般的な方向性は、可能な限り多くの柔軟性と生産性を提供し、絶対に必要な部分のみを最適化することでした。これを転換して、必要なだけの柔軟性を提供し、それ以外の場合は専用の実装を使用する必要があります。」

多くのソフトウェア機能にとって、メモリ アクセスは電力を最大に消費します。 「ソフトウェア機能はさまざまな方法で実装でき、その結果、さまざまな電力プロファイルとエネルギープロファイルを持つさまざまな命令ストリームが生成されます」とシノプシスの Ruby は述べています。 「メモリアクセス命令に重み付けするか、より高いコストを割り当てる必要があります。物事をモデル化する方法には注意する必要があります。たとえそれが単なる CPU であっても、システムのコンテキストでエネルギーのコストをモデル化する必要があります。」

将来的には、結果の精度も最適化に役立つ可能性があります。 Arteris の Boillet 氏は、「ソフトウェアを最適化して利用可能なハードウェア リソースを有効に活用することで、大幅な省電力を実現できます」と述べています。 「これには、コンパイラの最適化、計算の複雑さを軽減するためのコードのリファクタリング、エネルギー効率を高めるために特別に設計されたアルゴリズムが含まれます。後者は、マルチメディア処理、機械学習、センサー データ分析など、ある程度の不正確性を許容できるアプリケーションの近似コンピューティングによって実現できます。」

分析
すべては分析から始まります。 「システムの仮想モデルを作成できます」と Ruby 氏は言います。 「その後、ユースケースを定義することができます。この文脈では、これは実際には設計の一連の動作モードです。それはまだソフトウェアではありません。システムは、パフォーマンス モデルとパワー モデルの両方のモデルのコレクションとして記述されています。そして、これらのモデルと定義したユースケースに基づいた電力プロファイルが提供されます。次の代替案は、同様のタイプの仮想システム記述です。次に、それに対して実際のソフトウェア ワークロードを実行します。さらに深く掘り下げて、より可視性を高め、よりきめの細かい詳細が必要な場合は、デザインの RTL 記述を取得できます。おそらくそれはまだ最終的ではなく、まだ初期段階である可能性がありますが、ほとんどが揺れている限り、それを置くことができますエミュレータを使用して実際の作業を実行します。これを実行すると、エミュレータによってアクティビティ データベースが生成されます。エミュレーション指向の電力分析機能が存在し、大量のデータ、数億クロック サイクルのワークロード データを取得して電力プロファイルを生成できます。できることは多岐にわたります。」

場合によっては、それは十分な期間ではない可能性があります。 「当社の熱解析のほとんどは、解析に必要な配線長と時間がかかるため、プレシリコン シミュレーションではなく、シリコン データに基づいて構築された閉ループ解析に基づいています」と Intel の Kottapalli 氏は述べています。 「現実的な熱プロファイルを確立するために、それほど長い時間シミュレーションを行うことはできません。私たちはシリコンからのプロファイル データを使用し、さまざまな種類のワークロードとトレースを使用して、どのようなソリューションを構築する必要があるかを分析します。」

期間が短い場合は簡単です。 「基本的なアーキテクチャ上の決定は、ある種のパワービューを念頭に置いて検討する必要があります」と Ruby 氏は言います。 「すべてのプロセッシング コアやメモリ サブシステムを含むシステムのすべての部分について、より高レベルで抽象的なモデルが必要です。それがどのように編成されているかが非常に重要だからです。実際にどれくらいのメモリが必要なのでしょうか?これらは基本的なアーキテクチャ上の決定です。これらのコンポーネントに関連付けられた電力データが必要です。この特定のワークロードまたはその特定のワークロードで CPU はどのくらいの電力を消費しますか?チップ上の DSP コア、ハードウェア、メモリ、ネットワークはどうなるでしょうか。各操作を実行するときにそれぞれどれくらい消費しますか?これらは基本的なアーキテクチャ上の決定を行うために必要です。」

多くの新しい電力関連ツールが必要になります。 「高速、高電力密度の過渡現象に対処するための EDA ツールは存在しますが、他にも多くの課題があります」と Intel の Wilcox 氏は述べています。 「他の課題には、より長い時定数のダイナミクスや、SoC 全体で物事を管理する方法が検討されています。 EDA 分野でそれを支援しているものはあまり見たことがありません。私たちはこれらの機能を構築するために、さらに多くの自社製ツールを開発しています。」

こうしたアーキテクチャ上のトレードオフのハードウェア側向けにツールが開発されてきましたが、ソフトウェア側で役立つツールは現在ほとんど存在しません。 「当社のソフトウェア エンジニアは、できるだけ早く正しいコードを生成する必要があります」と Ruby 氏は言います。 「私が本当に必要としているのは、ソフトウェア開発者にとって何らかの付随テクノロジーであると信じています。ハードウェア用の RTL 電力解析ツールがあるのと同じように、ソフトウェア開発システムには、このコードがどれだけの電力とエネルギーを消費しているかを知らせる、ある種の電力プロファイラが必要です。今はAIの時代ですから、AI技術にコードを解析してもらえたらいいですね。消費電力の推定値が得られ、一部の AI テクノロジーは、コードを再構築すれば、この方法で大幅に電力を節約できると言うかもしれません。」

まとめ
ハードウェアの世界は電力とエネルギーに関連する壁にぶつかっています。そのコミュニティ内では熱の限界と懸念が高まっています。それらを考慮に入れなければ、ハードウェアの機能を拡張することはできません。しかし、これらはシステムレベルの懸念事項というレベルには達していません。エネルギー消費に関与するすべての関係者が同じ部屋に集まり、エネルギー効率が高くなるようにシステムを設計するまでは、この問題の真の解決策は見えません。

これには第二の側面もあります。人々が使用するツールを作成するすべての人々も同じ部屋に入り、全員が成功できるようにするフローを開発する必要があります。熱問題の一部を解決するために、EDA とシステムの世界の間にはある程度の進歩が見られましたが、アーキテクチャ レベルの進歩は少なく、ハードウェアとソフトウェアの世界の間にはほとんど進歩がありません。機能に重点を置いた仮想プロトタイプだけでは十分ではありません。これらはシステムの電力とエネルギーまで拡張する必要がありますが、それはコンパイラ開発者の関与なしには実現できません。これらの問題の結果として、これらの人々はハードウェアで新しい方向を向いており、隣接する分野で進歩を遂げるために十分重要である可能性があるため、ドメイン固有のコンピューティングにはチャンスがあります。しかし、それはずっと先のことになりそうだ。

関連レディング
チップの電力価格の高騰
より多くのデータにはより高速な処理が必要となり、多くの問題が発生しますが、そのすべてが明白ではなく、解決可能であるとは限りません。

スポット画像

最新のインテリジェンス

スポット画像

著作権 @ 2024 Plato Technologies Inc.