適応するか、消え去るか:コヒーレンシの統一理論

  • By Rajesh Ramanujam
  • 28th 7 2016
  • 1


進化とは自然の過程であり、より重要なことに比較的時間がかかるものです。こうした過程を経て、私たちは複雑なタスクを認識し、分析して処理できる段階にようやく到達しました。私たちは、環境、社会、状況が複雑になるにつれ、この異質な世界のるつぼの中で素早く瞬時に適応する方法を身に付けました。人気を得ることができるイメージを打ち出すことによって、有権者のニーズに適応する政治家から、キャンディをもう1つあげたくなるような愛らしさをアピールする5歳の子供まで、あらゆる年齢層でその兆候が見られます。要するに、絶えず変化する動的な世界において、適応性はきわめて重要なのです。

shutterstock_153575651

それと同様に、SoCのコヒーレンスアーキテクチャは、ソフトウェアベースのスヌープに基づく手法から、最新のディレクトリベースのスケーラブルなアーキテクチャなどのより高度なアプローチへと進化してきました。この進化のほとんどは、コア数の増加に対応し、レイテンシとバンド幅に関して性能を向上させるためにスケーラビリティを追求することによって促されました。

しかし、それで十分なのでしょうか。現在のSoCアプリケーションのさまざまな動的ワークロードに対応するには、どうすればよいでしょうか。このような変化する環境に合わせて再調整する能力なしに、これらのアーキテクチャは存続できるのでしょうか。

現在のアプリケーションには複雑な要件があり、ワークロードに基づいてシステムリソースへの要求が競合する可能性があります。モバイルアプリケーションでは、消費電力の効率化に適応性が求められるため、なおさらそうです。big.LITTLEなどの消費電力最適化テクノロジでは、ワークロードに基づいてCPUのオン/オフを切り替える機能を採用しています。GPUでは、固定小数点モードと浮動小数点モードの切り替えをサポートしている一方で、動的レンダリングモードを提供しているものもあります。MODEMをオフにできる一方で、動的ワークロードに対応するために、動的電圧および周波数スケーリング(DVFS)とソフトウェアによる省電力機能などの手法がSoCで使用されています。

ここでNoCはどのような役割を果たしているのでしょうか。NoCはこれらのIPすべてを接続する、SoCの不可欠な部分であるため、現在のNoCおよびコヒーレントアーキテクチャが動的な要件に適応することが強く求められています。

これらの実行時コヒーレンシへの要求と、コヒーレントアーキテクチャがリアルタイムでこれらの要求に適応できるようにするさまざまな機能について説明しましょう。

コヒーレンシは進化するだけでなく、適応する必要がある

コア/クラスタのシャットダウン非アクティブ化):現在のSoCでよく見られる機能は、消費電力を抑えるために特定のワークロードに対してプロセッサをシャットダウンするオプションです。これは実社会において、今後のより実りある会話のためにエネルギーを節約しようとして、気まずい会話を中断することで、楽な道を選ぶことと同じです。読者の皆さんのことはわかりませんが、私は義理の家族との会話で非常に頻繁にこの方法を使っています。ご心配なく。彼らがSemiEngineeringのブログを購読していないことは確かです。big.LITTLE構成(およびその他の非対称構成)では、各クラスタまたはコアは特定の負荷および性能に対して調整され、実行されているアプリケーションに応じて、一部のコアは動的にオフになるか、非アクティブ状態に切り替わります。このことは、主に次の2つの方法で活用できます。

ディレクトリの排除を減らすオフ(非アクティブ)になっているキャッシュを、コヒーレントなディレクトリで追跡する必要はありません。ディレクトリは、システム内のアクティブなキャッシュが使用できる重要なリソースです。

レイテンシの改善スヌープはレイテンシに影響を及ぼす可能性があります。プリフェッチの他に、どのキャッシュがオフになっているかを把握することで、スヌープを回避できるため、コヒーレントなトラフィックを生成する他のすべてのIPのコヒーレントなトラフィックのレイテンシを大幅に低減できます。

このような状況に対応するため、コヒーレンシアーキテクチャがこれらのモードを認識し、ディレクトリの排除を減らしてレイテンシを改善することによってこれらのモードを適切に活用できるように、インターコネクト内の各ポートの実行時プログラマビリティが求められています。

大容量キャッシュや外部のコヒーレントなシステムを備えたGPUのような一部のユースケースの場合、ディレクトリ内でそのキャッシュを追跡するのではなく、スヌープとしてマークを付ける方が効果的です。この場合は、ディレクトリを使用するコヒーレントなエージェントと、ディレクトリを使用しないコヒーレントなエージェントの組み合わせを、プログラムで指定できると便利です。それによって、ディレクトリのサイズを小さく、効率よく保つ一方で、一定のアドレス範囲に対するスヌープを回避することによってレイテンシを低減できる可能性があります。実行時プログラマビリティを備えていれば、ソフトウェアがそれらをディレクトリ追跡メカニズムに戻すかどうかを決定できます。


非コヒーレントなトラフィックと同様に、コヒーレントなトラフィックはさまざまな形状および形式で入ってきます。直接マッピングされたキャッシュとうまく連動するものもあれば、高アソシアティブキャッシュを要求するものもあります。現在のマルチスレッド化されたマルチコアシステムでは、すべてのトラフィックが同時に共存しており、すべての必要性と要求に対応できるインターコネクトが求められています。ほとんどのアーキテクチャにおいて、システムニーズに基づいてディレクトリのアソシアティビティを構成できます。しかし、アソシアティビティをトラフィックに動的に適応させることができると便利です。アソシアティビティは一般的なユースケースに合わせて設計時に構成されますが、このメリットは、実行時のトラフィックが必要に応じてさらに動的なアソシアティビティを利用できることです。これは、システム内部で行われて、ディレクトリの排除を減らし、その結果レイテンシを低減できます。

image1

動的に適応できるアソシアティブディレクトリを使用するNetSpeed GeminiSmartDirテクノロジ

IOコヒーレンシへの関与も動的な要求の1つになっています。どのIPがIOコヒーレンシにいつ関与する必要があるかは、実行されているアプリケーションに基づいてソフトウェアが決定します。一部のIOマスタには、アプリケーションのほとんどについてメモリ容量のコヒーレントなビューが必要ですが、さほど必要としないアプリケーションもあります。非コヒーレントからIOコヒーレントに切り替える必要がある、IOマスタの性能を微調整できる機能がアーキテクチャに備わっていることが理想的です。

ハードウェアでコヒーレンシを維持することは、性能と消費電力の両方の観点からコストがかかります。ハードウェアのコヒーレンシは、インターコネクトにおける余分な判断分岐点となり、これが全体的なクォリティオブサービス(QoS)に影響を与えないよう配慮する必要があります。さらに、完全にコヒーレントなトラフィックとIOコヒーレントなトラフィックは、アプリケーションのニーズに基づいて公平に扱われる必要があります。QoS機能は、アプリケーションレベルの要求を処理するだけでなく、不正なIPによって生成されたノイズと混雑も排除するよう、実行時プログラマビリティがあることが理想的です。その結果、実行時に変わり、時には相反する、現在のマルチコアSoCのトラフィックの要求に沿った堅牢なQoSアーキテクチャが実現されます。

最後に、コヒーレンシはこの10年余りの間に多くの劇的な変革を経て、良い方向へと向かってきました。SoCとマルチスレッド型コア、マルチコアシステム、非対称アーキテクチャ、複数のOS、動的ワークロード、および多様なアプリケーションの広範囲にわたる採用により、現在および将来の要求に合わせて再調整できる機敏なコヒーレントアーキテクチャの必要性が差し迫ったものとなっています。

Request A Demo

ajaxloader

Crafted @ Lollypop.biz