JP5750172B2 - 異種マルチコアシステム用のダイナミックコア選択 - Google Patents

Description

本発明は、特に電力およびパフォーマンスの効率を最適化するためのプロセッサ分野に関する。

半導体処理および論理設計の進化により、集積回路素子に含まれてよい論理量を増やすことが可能になっている。この結果、コンピュータシステム構成は、１つのシステムに１つまたは複数の集積回路が存在しているものから、個々の集積回路に、複数のコア、複数のハードウェアスレッド、および複数の論理プロセッサが存在するものへと進化を遂げている。通常、１つのプロセッサまたは集積回路は、１つの物理プロセッサダイを含んでおり、プロセッサダイは、任意の数のコア、ハードウェアスレッド、または論理プロセッサを含んでよい。

増加の一途を辿る、集積回路上のプロセッサエレメント（コア、ハードウェアスレッド、および論理プロセッサ）によって、より多くのタスクを並列処理することが可能となっている。しかし、全てアウトオブオーダコアを利用するプロセッサは、条件によって電力非効率および／またはパフォーマンスの非効率に陥りやすい。この結果、電力−パフォーマンスの効率問題に対処すべく、ハードウェア−ソフトウェア共同設計システムが開発された。このシステムでは、幅広く、簡単なインオーダプロセッサを利用することができ、同時に、ソフトウェアが、インオーダハードウェアで効率的に実行されるようにプログラムを最適化させたりスケジュールしたりすることができる。

しかし、ハードウェア−ソフトウェア共同設計システムでは、通常、２つの悪影響が指摘されている。つまり、（１）バイナリトランスレータを利用するコードの変換および／または最適化によって、短い実行タスクの、応答時間制約の小さい一部のアプリケーションの処理速度が落ち（バイナリ変換の脆弱性）、（２）インオーダプロセッサが、並列実行により適している一部のプログラムのスタイルにはパフォーマンスがよくない（インオーダの脆弱性）がある。

本発明を例示するが、添付図面によって制限はされない。

２つの異種コアを含むプロセッサの一実施形態を示す。 ネイティブコア、ソフトウェア管理されているコア、およびコア分配モジュールを含むプロセッサの一実施形態を示す。 最大のパフォーマンスおよび節電効果を達成するために、コア間にコードを分配するプロセッサのフロー図の一実施形態を示す。 最大のパフォーマンスおよび節電効果を達成するために、アウトオブオーダコアおよびインオーダコアにコードを分配する方法のフロー図の一実施形態を示す。 最大のパフォーマンスおよび節電効果を達成するために、アウトオブオーダコアおよびインオーダコアにコードを分配する方法のフロー図の別の一実施形態を示す。 本発明の一実施形態におけるコア切り替えオペレーションおよびオーバヘッドを示す。

異種コンピューティング戦略は、それぞれのコアが特定のコードを実行するのには効率がよいが、他のコードを実行するのには効率が悪いような複数のコアを統合するものである。ランタイムソフトウェア（ＳＷ）およびハードウェア（ＨＷ）は、協力して、入力プログラムを、別々のコアに適したコードセグメントに分割して、これらそれぞれを最も適したコアの上で実行して、同時に、他のコアを低電力状態にしておき、低電力およびエネルギー消費において高いパフォーマンスを達成する。このようなシステムの一例は、少なくとも１つの広帯域インオーダコアと、少なくとも１つの狭帯域アウトオブオーダコアとからなり、本発明の実施形態においては、この異質システムが、アウトオブオーダコアのパフォーマンスを向上させ、且つ、エネルギーおよび電力の一部しか消費しない。このタイプのコンピューティングシステムの主要な課題は、プログラムの振る舞いの変化を迅速に特定して、適切なコアにランタイムにおいて効率的にスイッチする、ということである。本発明の実施形態では、ランタイムソフトウェアおよび／またはハードウェアを利用して、同じプログラムの別々のコードセグメントを最も適したコアの実行を自動的に切り換えて、シングルスレッドプログラムのパフォーマンス速度を顕著に速くする。

以下の記載では、具体的なプロセッサコアの種類、具体的なプロセッサ構成、具体的なホットコード領域特定アルゴリズム、変換／最適化コードを格納する具体的な構造、ハードウェア／ソフトウェアの間のタスクの具体的な分割法、具体的なプロセッサユニット／論理等についての例など、複数の具体的な詳細を述べ、本発明の完全な理解を提供している。しかし当業者には、本発明を実施するためにこれらの具体的な詳細が必ずしも利用されなくてもよいことが明らかである。また、公知のコンポーネントまたは方法（たとえば特定およびその他のプロセッサアーキテクチャ、記述されたアルゴリズム用の具体的な論理回路／コード、具体的なコード実装、具体的なバイナリ変換の詳細、およびその他のマイクロプロセッサの具体的なオペレーションの詳細）は、詳述を避けて、本発明の不当にあいまいにしないようにしている箇所もある。

一実施形態では、ここの記載する方法および装置は、最大のパフォーマンスおよび節電効果を実現するために、ソフトウェア管理されているコアをもつネイティブコアを実装することである。特に、コア間の協力は、まず一義的に、アウトオブオーダコアおよびインオーダの共同設計コアを参照して説明する。しかし、ここに記載する装置および方法は、これらに限定はされず、異種コア間でコードを分配するいずれの様式に実装することもできる。たとえば、ここで記載するコード分配方法および装置は、固有の命令セットアーキテクチャ（ＩＳＡ）を実装する２つのアウトオブオーダコアとともに利用することもできる。さらに、これらコアの間の協力が、しばしば、ハードウェアメカニズムおよびコード／ソフトウェアの間で分割されるものとして記載される場合がある。しかし、後述する方法および装置を実装するために利用可能なハードウェア、ソフトウェア、および／またはファームウェアは適宜組み合わせまたは排他的利用することが可能である。

図１は、複数のコアを含む１つのプロセッサの一実施形態を示している。プロセッサ１００は、マイクロプロセッサ、エンベデッドプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、ネットワークプロセッサ、またはコードを実行するその他のデバイス等の任意のプロセッサであってよい。一実施形態では、プロセッサ１００は、それぞれ異なる種類のコア１０１および１０２という少なくとも２つのコアを含む。しかし、プロセッサ１００は、任意の数の処理エレメントを含んでよい。

一実施形態では、処理エレメントは、スレッドユニット、スレッドスロット、処理ユニット、コンテキスト、論理プロセッサ、ハードウェアスレッド、コア、および／または、プロセッサの状態（たとえば実行状態またはアーキテクチャ状態）を維持することができる任意の他のエレメントのことであってよい。言い換えると、一実施形態において処理エレメントとは、ソフトウェアスレッド、オペレーティングシステム、アプリケーション、その他のコードといったコードに独立して関連付けることができる任意のハードウェアのことであってよい。物理的なプロセッサは通常、コアまたはハードウェアスレッドといった任意の数の他の処理エレメントを潜在的に含むことができる集積回路のことであってよい。

コアは、それぞれ独立して維持されるアーキテクチャ状態が少なくともいくつかの専用実行リソースと関連付けられている独立アーキテクチャ状態を維持することができる集積回路上に位置する論理のことを指す場合が多い。コアに対して、ハードウェアスレッドとは、通常、独立して維持されるアーキテクチャ状態が実行リソースに対するアクセスを共有する独立アーキテクチャ状態を維持することができる集積回路上に位置する任意の論理のことである。上記からわかるように、特定のリソースが共有されている場合、他のリソースはアーキテクチャ状態専用であり、ハードウェアスレッドとコアとの境目は曖昧である。しかししばしば、コアとハードウェアスレッドとは、オペレーティングシステムから個別の論理プロセッサとみられており、オペレーティングシステムは、各論理プロセッサ上での動作を個々にスケジュールすることができる。

物理的プロセッサ１００（図１に示す）は、２つのコア（コア１０１および１０２）を含む。ここでコア１０１およびコア１０２は、異質コアと考えることができる（つまり、それぞれ異なる構成、機能ユニットおよび／または論理をもつコアのこと）。一実施形態では、コア１０１は、アウトオブオーダプロセッサコアを含み、コア１０２が、インオーダプロセッサコアを含む。しかしコア１０１および１０２は、任意のタイプのコアから個々に選択されてよい。しかし説明を続けるために、図１に示す機能ユニットを以下で詳述する。

記載したようにコア１０１は、２つのハードウェアスレッド１０１ａおよび１０１ｂを含み、これらは、ハードウェアスレッドスロット１０１ａおよび１０１ｂとも称される場合がある。これに対して、コア１０２は、１つのハードウェアスレッド１０２ａを含んでいる。したがって、ソフトウェア実体（たとえばオペレーティングシステム）は、一実施形態では、プロセッサ１００を、３つのソフトウェアスレッドを同時に実行することができる３つの別個のプロセッサ（つまり３つの論理プロセッサまたは処理エレメント）とみなす。この代わりに、ソフトウェア実体は、プロセッサ１００を、２つの別個のプロセッサ（スレッドスロット１０１ａおよび１０１ｂ）をもつものとしてみなすこともでき、記載するコードの分配メカニズムが、コア１０２上でのコードに実行を管理する。

第１のスレッドは、アーキテクチャ状態レジスタ１０１ａに関連付けられており、第２のスレッドは、アーキテクチャ状態レジスタ１０１ｂに関連付けられており、第３のスレッドは、アーキテクチャ状態レジスタ１０２ａに関連付けられていてよい。図示するように、アーキテクチャ状態レジスタ１０１ａは、アーキテクチャ状態レジスタ１０１ｂに複製されており、個々のアーキテクチャ状態／コンテキストが、論理プロセッサ１０１ａおよび論理プロセッサ１０１ｂのために格納可能である。アーキテクチャ状態レジスタ１０２ａは、レジスタ１０１ａ、１０１ｂと同じであってもよい。または、レジスタ１０２ａが、コア１０２のアーキテクチャに固有であってもよい。コア１０１では、他のより小さいリソース（たとえば、リネームアロケータ論理１３０の命令ポインタおよびリネーミング論理）も、スレッド１０１ａおよび１０１ｂ用に複製されてよい。一部のリソース（たとえば、リオーダ／リタイヤユニット１３５のリオーダバッファ、命令−変換バッファ（ＩＴＬＢ）１２０、ロード／格納バッファ、およびキュー）が、分割によって共有されてもよい。他のリソース（たとえば、汎用内部レジスタ、ページ−テーブルベースレジスタ、低レベルデータ−キャッシュおよびデータ−ＴＬＢ１５０、実行ユニット１４０、およびアウトオブオーダユニット１３５の幾つかの部分）が、潜在的に完全共有されてもよい。

しばしばプロセッサ１００は、完全共有されていたり、分割により共有されたり、処理エレメント専用であったりしてよい他のリソースを含む場合がある。図１では、プロセッサの例示的な論理ユニット／リソースをもつ、純粋に例であるプロセッサの実施形態が示されている。プロセッサは、これら機能ユニットのいずれかを含んでも、含まなくてもよく、同時に、図示されていない任意の他の公知の機能ユニット、論理、またはファームウェアを含んでもよい。図では、コア１０１は、単純化されたアウトオブオーダ（ＯＯＯ）プロセッサコアとして示されている。ＯＯＯコアは、実行／とられるべき分岐を予測するための分岐対象バッファ（ＢＴＢ）１２０、および、命令用にアドレス変換エントリを格納するための命令−変換バッファ（Ｉ−ＴＬＢ）１２０を含む。

コア１０１はさらに、フェッチユニット１２０に連結されて、フェッチされたエレメントをデコードするためのデコードモジュール１２５を含む。一実施形態では、フェッチ論理は、それぞれ、スレッドスロット１０１ａ、１０１ｂに関連付けられている個々のシーケンサを含む。通常、コア１０１は、プロセッサ１００上で実行可能な命令を定義／特定する第１の命令セットアーキテクチャ（ＩＳＡ）に関連付けられている。ここで、しばしば、第１のＩＳＡの一部である機械コード命令が、実行すべき命令またはオペレーションを参照／特定する、命令の一部（オペコードと称される）を含む。デコード論理１２５は、これら命令を自身のオペコードから認識して、デコードされた命令を、第１のＩＳＡが定義する処理を受けさせるためにパイプラインに送る回路を含んでいる。

一例では、アロケータリネーマブロック１３０が、結果を処理する命令を格納するリソース（レジスタファイル）をリザーブするアロケータを含む。しかしスレッド１０１ａおよび１０１ｂは、潜在的に、アウトオブオーダ実行をすることができ、アロケータおよびリネーマブロック１３０も、他のリソース（たとえば、命令ステータスを追跡するためのリオーダバッファ）を含んでよい。ユニット１３０は、さらに、プログラム／命令参照レジスタをプロセッサ１００内部の他のレジスタにリネームするレジスタリネーマを含んでよい。リオーダ／リタイヤユニット１３５は、コンポーネント（たとえば上述したリオーダバッファ、ロードバッファ、および格納バッファ）を含み、アウトオブオーダ実行をサポートして、後では、アウトオブオーダ実行された命令のインオーダリタイヤをサポートする。

スケジューラおよび実行ユニットブロック１４０は、一実施形態では、実行ユニットの命令／オペレーションをスケジュールするためのスケジューラユニットを含む。たとえば、浮動小数点命令が、利用可能な浮動小数点実行ユニットを有する実行ユニットの一部に対してスケジュールされる。実行ユニットに関連づけられているレジスタファイルも、結果を処理する情報命令を格納するために含まれている。例である実行ユニットは、浮動小数点実行ユニット、整数実行ユニット、ジャンプ実行ユニット、ロード実行ユニット、格納実行ユニット、およびその他の公知の実行ユニットを含む。

低レベルデータキャッシュおよびデータアドレス変換ルックアップ／サイドバッファ（Ｄ−ＴＬＢ）１５０が、実行ユニット１４０に連結されている。データキャッシュは、エレメントに最近利用された／操作されたものを格納する（たとえば、メモリコヒーレンシー状態に潜在的に維持されているデータオペランド）。Ｄ−ＴＬＢは、物理的アドレス変換に対して最近の仮想／リニアを格納する。具体的な例としては、プロセッサは、物理的メモリを複数の仮想ページに分割するためにページテーブル構造を含んでよい。

上述したように、一実施形態では、コア１０２が、インオーダ、共同設計コアを含む。この結果、図１は、インオーダコアの簡略化されたパイプラインを示している。このパイプラインは、フェッチユニット１２１、デコードユニット１２６、実行ユニット（１または複数）１４１、および低レベルデータキャッシュ１５１を含む。これらユニットは、コア１０１の対応するユニットに同様に動作してよい。しかしインオーダコアでは、命令／オペレーションが、プログラム順に実行される（コア１０１におけるような潜在的なアウトオブオーダ実行ではなく）。一例としては、アウトオブオーダコア１０１が、ネイティブコアと称され、インオーダコア１０２は、共同設計コアと称される。この代わりに、インオーダコア１０２が、ネイティブコアであり、アウトオブオーダコア１０１が共同設計コアであってもよい。

ここで、コア１０１および１０２は、最近フェッチされたエレメントをキャッシュするための、より高レベルまたはさらに外側の（further-out）キャッシュ１１０に対するアクセスを共有する。ここで、より高レベルまたはさらに外側とは、キャッシュレベルが増加する、または、実行ユニットからさらに離れることを意味している。一実施形態では、より高レベルのキャッシュ１１０が、最終レベルデータキャッシュである（第２または第３レベルデータキャッシュのような、プロセッサ１００のメモリ階層で最終のキャッシュ）。しかし、より高レベルキャッシュ１１０は、命令キャッシュに関連付けられていれば、または、命令キャッシュを含んでいればいいのであって、これに限定はされない。追跡キャッシュ（命令キャッシュの一種）が、この代わりに、デコーダ１２５の後に連結されていて、最近デコードされたトレースを格納してもよい。

図示されている構成では、プロセッサ１００はさらに、リンクインタフェースモジュール１０５を含み、プロセッサ１００外のデバイス（たとえば、システムメモリ１７５、チップセット、ノースブリッジ、その他の集積回路（たとえば「システムオンチップ（system on a chip）（ＳＯＣ）」等の１つの集積回路実装）を含む）と通信する。メモリ１７５は、プロセッサ１００専用であっても、システム内の他のデバイスと共有されてもよい。メモリ１７５の種類のよくある例としては、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、スタティックＲＡＭ（ＳＲＡＭ）、不揮発性メモリ（ＮＶメモリ）、その他の公知の記憶デバイスが含まれる。

一実施形態では、コードが、コア１０１および１０２の間で、最大のパフォーマンスおよび節電効果に基づいて分配される。たとえば、コード領域が、２つのコア１０１、１０２のいずれかにより良く実行されるように特定される。この結果、これらコード領域のいずれかに遭遇したり、これらコード領域のいずれかを検知したりするとき、このコードセクションが適切な分配されることになる。これら領域の特定は、静的に（コードの実行前、たとえばプログラムプロフィール分析によって）行われてもよいし、ハードウェア、ソフトウェア、またはこれらの組み合わせによって動的に（コードの実行中に）行われてもよい。

動的な方法の一例では、１つのプロセッサコア（たとえばコア１０１）が、パフォーマンス、節電、ネイティブＩＳＡ，任意の他の公知の処理の考慮、またはこれらの組み合わせに基づいてコードを実行するデフォルトコアとして選択されてよい。そして、コア１０１での実行状態が良くない、または、コア１０２での実行状態のほうが良いと見込まれるデフォルトコアの領域を特定する。後でこれら特定されたコードのセクションに遭遇すると、実行されるべくコア１０２に分配される。これら領域のコア１０２における実行には、ウォームアップコア１０１に対する投機的、ランアヘッド実行、コア１０２のこれら領域に対するシリアル実行と、これら領域の結果に依存するコア１０１の他の領域に対する実行との組み合わせ、または、これらの領域の同時実行と、コア１０２の他のコードの実行との組み合わせが含まれてよい。

静的な方法の一例では、コンパイラまたはユーザが、あるコアその他のコアでより良く実行されるコードのセクションを特定してよい（たとえば、命令またはデマケーションにより）。ここで、コア１０１は、これらの命令に遭遇するまではコードを実行する。コア１０２からの監視に呼応する、または、コア１０２単独の判断（トリガ）によって、特定されたコードのセクションを次に、遭遇した命令に基づいてコア１０２で実行する。

１つのコアまたは別のコアでの実行するほうが良いコードのセクションの特定を、動的または静的に行うかによって、一部の実施形態では、ネイティブコードを別のコアで実行するよう変換したり、および／または、最適化したりする。たとえば、コア１０１が、第１のＩＳＡタイプを認識するデコード論理１２５を含み、コア１０２が、第２のＩＳＡタイプを認識するデコード論理１２６を含むと想定する。この場合、第１のＩＳＡタイプのコード領域が、コア１０２で実行され、次に、コード領域を第２のＩＳＡタイプに変換して、コア１０２で実行させる。ＩＳＡタイプの間の変換は純粋な例である。この代わりに、コア１０１で実行されるアウトオブオーダ最適化コードを、インオーダコア１０２の実行用に再度最適化する。このシナリオでは、コア１０２は、同じもの、またはコア１０１の同じＩＳＡのサブセットを含んでよい。または、最適化を、コードに行って、単純な、広帯域のイノーダコアに確実により効率的に実行されるようにしてもよい。

コードを効率的に分配するための、コア１０１とコア１０２との間の協力は、ハードウェア、ファームウェア、ソフトウェア、またはこれらの組み合わせで実行されてもよい。上述した、コード領域を特定するために動的な方法に関する例をさらに照査して、協力メカニズムの実施形態を説明する。この例では、ネイティブフォーマットのプログラムコードが、アウトオブオーダコア１０１での実行用に最適化される。コード領域またはプログラムコードの実行中に、コア１０１および／またはコア１０２に関するモニタハードウェアが、コード領域のコア１０１の実行に関するパフォーマンスを決定するために利用されてよい。この代わりに、ソフトウェア、ＯＳコード、マイクロコード、またはその他のコード等のモニタハードウェアが、コア１０２で実行され、これによりコード領域の実行の際のコア１０１のパフォーマンスを判断／監視してもよい。そのコード領域がコア１０２で実行されるほうがよいと判断されると、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせを利用して、コア１０２で実行するコード領域を変換および／または最適化してよい。

この結果、コア１０１がコード領域に再度遭遇すると（命令ポインタがコード領域を参照すると）、コード領域を識別する識別子命令がフェッチされデコードされ、または、コード領域を特定する別の方法が検知され、次に、コード領域の変換／最適化されたバージョンがコア１０２で実行される。一実施形態では、コード領域がコア１０２で実行されている間、コア１０１は、他のコード領域を同時に実行して、プログラム実行パフォーマンス全体を高める。同時または並列実行は、コア１０１、１０２での別個のソフトウェアスレッド実行を含んでよい。

これに対して、スレッドは、コア１０１、１０２でパイプライン実行されてよい。このシナリオの一例として、２つのソフトウェアスレッドの各々が、多くのコード段階（ホット、コールドなど）を含むと想定する。ここで、第１のステッドからのコールドコードは、コア１０１で実行されてよく、ホットな領域に遭遇すると、変換されたホットな領域をコア１０２で実行する。コア１０２でコードの変換されたホットな領域が実行されている間、第２のスレッドからのコールドコードがコア１０１で実行されてよい。コア１０２では、第１の変換されたホットコードの実行が完了すると、第２のソフトウェアスレッドからの別のホットな領域の実行が開始されてよい。この例からわかるように、コードの段階は、パイプラインタイプの実行を生じる各コアにインタリーブされてよい。別の実施形態では、コードが、２つのコア（コア１０１のコード領域、コア１０２で特定されたコード領域、その後に、コア１０１の別のコード領域といったように）に対して連続実行されてよい。

加えて、コード領域がコア１０２での実行のために最初に特定された場合であっても、その実行のパフォーマンスを監視することができる。次に、最大のパフォーマンスおよび節電効果を達成するためにどのコアがコード領域の実行に最も適しているかを判断するために、両方のコアのパフォーマンスが考慮されてもよい。たとえば、あるコード領域が、コア１０２上で変換されたコードとして実行されるものとして特定されたが、コア１０２でのパフォーマンスがコア１０１でのパフォーマンスを下回るような場合（または、コア１０２でのパフォーマンス利得が、コア２０１で実行される際の節電量を上回らないような場合）、後で遭遇したときに、コア１０１に対してコードを再分配することができる。

図１は、それぞれ別のモジュール、ユニット、および／または論理を表す、例示的なプロセッサの抽象的な論理図である。しかし、ここで記載する方法および装置を利用するプロセッサは、例示したユニットを含まなくてもよい点を理解されたい。プロセッサは、示されているユニットの一部または全てを含まなくてもよい。さらに、記載の大半は、アウトオブオーダプロセッサコアとインオーダプロセッサコアとを参照して行われる。しかし、上述したように、２つのプロセッサコアは、異種のコアバージョンであればいずれであってもよい（たとえば、ネイティブコアとソフトウェア管理されているコア等）。加えて、図１は２つのコアのみを示しているが、プロセッサは任意の数のコアを含んでよい（たとえば、同じタイプの複数のコア、および、互いにタイプの異なる２を超える数のコア）。

図１は、外部メモリコントローラ（コントローラハブ１７０）に対するインタフェースを有するポイントツーポイント法で連結されたプロセッサの一実施形態を示す。しかし、既に数多くのプロセッサ（複数のコア、および共有キャッシュおよびその他のインタフェースをインターコネクトするリング構成を有するオンプロセッサメモリインタフェースモジュール（オンチップモジュール））が存在している。図示はされていないが、一実施形態では、プロセッサ１００が、コア、キャッシュ、およびメモリコントローラコンポーネントを連結するリングインターコネクトを含んでいる。

ここで、キャッシュエージェントを利用して、物理的に分配しているキャッシュのスライスを管理することができる。一例としては、各キャッシュコンポーネントが、配列コア（collocated core）（キャッシュエージェントが、キャッシュの分配されたスライスを管理する目的のために関連付けられているコア）のためのキャッシュのスライスを管理する。キャッシュエージェントがキャッシュスライスとのリングインターコネクトおよびインタフェースのトラフィックを取り扱うのと同様に、コアエージェント／コンポーネントが、コアとのトラフィックおよびインタフェースを取り扱う。加えて、リングインターコネクトは、メモリコントローラインタフェース論理（ＭＣＩＬ）および／または他のコントローラを連結して、他のモジュール（たとえばメモリおよび／またはグラフィックプロセッサ）とインタフェースさせてよい。

図２を参照すると、２つのコア間でコードを分配させるコード分配モジュールの一実施形態が示されている。一実施形態では、コア２０１、２０２が、異種コアである。たとえばコア２０１は、元のプログラム順序ではない順序でコードを実行するよう適合されているアウトオブオーダ（ＯＯＯ）コアであり、コア２０２は、プログラム順序でコードを実行するよう適合されているインオーダ（またはシリアルコア）である。他のコアのタイプの非包括的な例のリストには、ネイティブコア、非ネイティブコア、ソフトウェア管理されているコア、ネイティブＩＳＡコア、変換されたＩＳＡコア、共同設計コア、投機的実行コア、および非投機的コアが含まれる。

一実施形態では、コード分配モジュール２１０が、コードをコア２０１および２０２の間で、最大のパフォーマンスおよび節電効果に基づいて分配させる。ここで利用するモジュールは、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせのことであってよい。加えて、モジュール、ユニット、または論理は、１つのコアまたはプロセッサに集中されていても、全体に分散されていてもよい。たとえば、コード分配モジュール２１０は、マイクロコードまたはソフトウェア等の、コア２０１、コア２０２、プロセッサ２００、またはプロセッサ２００を含むシステムに関連付けられているストレージに保持されている分配コードを含んでよい。ここで、分配コードは、実行されると、コードの分配を実行する。これに対して、コード分配プロセスは、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせで管理されてよい。

一実施形態では、コード分配モジュール２１０は、プログラムコードの実行をあるコアから別のコアへと動的に切り替える。動的切り替えプログラムコードは、図４および図５を参照して後で詳述する。しかし、このセクションの説明としては、プログラムコードは、処理エレメント（たとえばバイナリまたは機械コード）で実行される任意のコードを含んでよい。コードのホットな部分は、考慮要件（たとえば電力、パフォーマンス、熱、その他の公知のプロセッサメトリック、またはこれらの組み合わせ）に基づいて、他よりあるコアで実行するほうが適しているコードの部分のことであってよい。ここで、コア２０１が、プログラムコードのネイティブ実行のためのデフォルトのコアであると想定すると、プログラムコードのホットな部分の特定は、コア２０２での実行により適しているコードの部分を判断することを含む。コア２０１がＯＯＯコアでありコア２０２がインオーダコアである実施形態では、コードのホットな部分が、シリアルコア２０２での実行により適したプログラムコードのホットスポットのことであってよく、この部分は、潜在的に高い反復セクションの実行のためにより有用なリソースを有している可能性がある。一例として、コードのホットな部分を、コードのその部分の反復パターンで特定し、または、その他の公知のメトリックで特定する（たとえば命令カウントまたはサイクルカウント）。反復の可能性が高く（high-recurrence）、予測可能なレイテンシーパターンをもつコードのセクションが、しばしば、インオーダコアでより有効に実行されるよう最適化されるとよい場合が多い。本質的には、この例で、コールドコード（反復の可能性が低い（low-recurrence））は、ネイティブのＯＯＯコア１０１に分配され、ホットコード（反復の可能性が高い）は、ソフトウェア管理されているインオーダコア１０２に分配される。

コードのホットな部分は、静的に、動的に、またはこれらの組み合わせで特定することができる。最初の場合、コンパイラまたはユーザは、プログラムコードのセクションがホットコードであると判断してよい。ここで、ホットコード識別子命令は、コードの一セクションをホット（コア１０１でではなくてコア２０２で実行される）として区別する（demarcate）することができる。コア２０１のデコード論理は、一実施形態では、プログラムコードからホットコード識別子命令をデコードするよう適合されており、これは、プログラムコードのホットな部分を特定する。これらの命令のフェッチまたはデコードは、コア２０２におけるコードのホットなセクションの変換および／または実行をトリガしてよい。この例では、コード分配モジュール２１０は、ホットコード検知命令を検知するデコード論理を含む。そしてモジュール２１０は、さらに、コア２０２におけるホットコードの変換／最適化および実行を行う他のハードウェアおよび／またはソフトウェアを含んでよい。この代わりに、ホットコードのセクションは、コア２０２での実行のために予め最適化／変換されてよい。

別の例においては、コード分配モジュール２１０は、動的に（実行中に）、プログラムコードのホットスポット／領域を特定する。一実施形態では、コア２０１および／またはコア２０２に含まれているハードウェアは、コア（たとえばコア２０１）におけるプログラムコードのプロフィール実行を行うために利用される。プロフィールの特徴に基づいて（実行にまつわる電力および／パフォーマンスメトリック）、プログラムコードの１つの領域をホットコードとして特定することができる。ハードウェアのオペレーションに類似して、監視コードを１つのコア（たとえばコア２０２）の上で実行して、他のコア（コア２０１）で実行されているプログラムコードの監視／プロフィールを実行してよい。このような監視コードは、プロセッサ２００内のコア内の格納構造に維持されたり、プロセッサ２００を含むシステムで維持されたりするコードであってよい。たとえば、監視コードは、コア２０１、コア２０２、またはプロセッサ２００の格納構造に維持されるマイクロコードまたはその他のコードであってよい。そして、監視コードは、従来の実行ユニットおよびプロセッサ２００の他のファームウェアまたは論理によって実行されてよい。

また別の例として、ホットコードの静的識別が、ヒントとして作成される。しかしプログラムコード実行の動的プロファイルは、コードの一領域のホットとしての静的な識別を無視することができ、このタイプの静的識別はしばしば、動的プロファイルがコード分配に適したコアを判断する際に考慮するコンパイラまたはユーザヒントとして参照される。さらに、動的プロファイルの性質として、コードの１つの領域をホットとして特定することによって、コードのそのセクションが常にホットとして特定されるわけではない。たとえば、プログラムコードがアウトオブオーダコア２０１で実行されていると想定する。コア２０２で実行されている監視コードは、プログラムコードの１つのセクションのコア２０１の実行のパフォーマンスレベルを監視する。実装に基づき、コア２０１のパフォーマンスが、コア２０２で実行されるよりも十分低いと判断されると、および／または、コア２０１におけるコードのセクションの反復パターンが、コアの遷移オーバヘッドを隠すと予測することができる程度に十分高いと判断されると、コードのセクションをホットとして特定する。変換および／または最適化の後に、コードのセクションの変換されたバージョンをコア２０２で実行する。コア２０１における実行の監視同様に、たとえばパフォーマンス監視コードの実行によって、コードの変換されたバージョンの実行もコア２０２で監視されてよい。パフォーマンスがコア２０１におけるよりコア２０２においてのほうが低い場合には、コードのセクションをホットと特定することを、動的に逆にすることもできる（ホットコードのセクションをコールドコードとして命名しなおしてよい）。

ひとたびコードのあるセクション、スポット、または領域がホットとして特定されると、コード分配モジュール２１０は、一実施形態では、コードのホットなセクションを最適化および／または変換して、最適化／変換されたホットコードを得る。一実施形態では、バイナリ変換コード等の変換および／または最適化コードが、コア２０２の格納論理に維持される。一例として、バイナリ変換コードは、コア２０２に維持されているマイクロコードの一部であってよい。変換／最適化コードは、実行されると、コア２０２での実行用にコードのセクションを変換／最適化する。一実施形態では、コア２０１、２０２は、同じＩＳＡまたはそのサブセットを認識することができ、ここでの変換／最適化は単に、コードを変換／最適化して、より効率的にコア２０２で実行できるようにすることであってよい。別の実施形態では、コア２０１、２０２が、異なるＩＳＡを認識して、ここでは、変換が、コア２０１が認識可能な１つのＩＳＡからのコード領域を、コア２０２が認識可能な別のＩＳＡに変換することを含む。変換／最適化は、変換／最適化コードの実行の観点から説明されているが、任意の変換／最適化コードのメカニズムを利用することができる（専用ハードウェアを利用する場合であっても）。

一実施形態では、ホットコードの特定されたセクションにコア２０１で遭遇すると、ホットコード（その変換されたバージョン）が、コア２０２で実行される。ホットコード領域に遭遇する時を判断するための公知のトリガを利用することができる。高レベルの例のいくつかとして、コード領域に関連付けられている命令アドレスに遭遇／参照すること、コードのセクションをホットコードとして特定する命令をフェッチ／デコード／スケジュールすること、が含まれており、ホットコードの変換されたバージョンを示す命令をフェッチ／デコード／スケジュールすることは、別のコアで実行され、ホットコード領域を示すモニタからの外部トリガに遭遇すること等が含まれている。

例では、コード分配モジュール２１０が、ハードウェア、ソフトウェア、またはこれらの組み合わせで実装されるモニタモジュールを含む。モニタモジュールが、コードのホットな領域を特定している、または、ホットな領域を変換された領域に変換している場合、モニタモジュールは、コードのホットな領域に関する命令アドレスを登録する。登録には、コードの変換された領域の位置との、命令アドレスの関連付けが含まれていてよい。そして、後で命令ポンタ（プログラムカウンタ）が、命令アドレスにアクセスすると、登録されている命令アドレスから、コードのホットな領域に遭遇したと判断する。ここでは任意の形態の検知を利用することができる（たとえば、遭遇イベントの同期または非同期の割り込み処理スタイル）。加えて、ハードウェア、マイクロコード、および／または、ファームウェアが、割り込みのような処理、つまり、ハンドラによりトリガイベントが行われることなくなしに、ホットコードセクションの遭遇を直接処理することができてよい。コア１０１および１０２は、マッピング構造等の特定のハードウェア構造を共有して、登録されているアドレスをホットコードとして特定することができる。

コア２０１でホットコードセクションに遭遇すると、ホットコードセクションの変換された、および／または、最適化されているバージョンがコア２０２で実行される。ホットコードセクションがどのようにコア２０１で特定または遭遇された場合であっても、別のコアでコードの実行を可能とする任意の公知の方法を利用することができる。一実施形態では、協力モジュールを利用してこのような実行を行うことができる。たとえば、コア２０１、２０２は、特定のハードウェア構造を共有したり、および／または、情報共有のための通信チャネルを含んだりすることができる。一例としては、コア１０１、１０２が、データキャッシュを共有してよいので、たとえば実行がコア２０１から２０２に移る場合などに、データを物理的に移動させるのではなく、共有キャッシュに既に存在させておくことができる。同様に、シャドウレジスタファイル等のレジスタファイルを、一実施形態で、コア２０１および２０２の間で共有することができるので、レジスタ状態（コンテキスト）を１つのコアから別のコアへと移す必要がない。この代わりに、レジスタファイルを共有する代わりに、高速インターコネクトを利用して、１つのコアから別のコアへと物理的にコンテキストまたはその一部を移すことができる。これに加えて、あまり頻繁に移されないソフトウェアを利用して移送を行うこともできる。

一例として、ホットコードセクションに対する入力値が、コア２０１からコア２０２へ返送されて、コア２０２のホットコードセクションの実行をサポートする。実行の後に、出力値がコア２０１に戻される。一実施形態では、コードセクションから特定された入出力値のみを移すことができる（つまり、部分的なコンテキストスイッチ）。この入力値は、ユーザが（ソフトウェア／コンパイラ）および／またはハードウェア／ファームウェアアルゴリズムによって移すことができてよい。ここで、直接アクセスハードウェアは、レジスタ、バッファ、コア２０１のその他の構造から入力値を読み出し、コア２０２に書き込むことができるよう適合されていてよい。この逆に、同じまたは異なるハードウェアを利用して、コア２０２から値を読み出し、コア２０１に書き込むことができる。しかし、これら値の特定が非常に面倒である場合には、コア２０１と２０２との間に値を提供するために、完全なコンテキストスイッチ、複製、または共有を実行してよい。

次に図３を参照すると、コードをコア間に分配して、最大のパフォーマンスおよび節電効果を達成するためのプロセッサの一実施形態が示されている。上述したように、プロセッサ３００は、２つのプロセッサコア（それぞれが異なるコアタイプである）を含んでいる。一例では、コア３０１はネイティブの、アウトオブオーダ（ＯＯＯ）プロセッサコアであり、コア３０２がソフトウェア管理されている、インオーダプロセッサコアである。コア３０１および３０２は、必須ではないが、異なるＩＳＡタイプを認識するものであってよい。実際、コア３０２は、コア３０１のＩＳＡのサブセットを認識することができる。または、コア３０２が、コア３０１のＩＳＡと部分的に重なる別のＩＳＡを含んでもよい。上述したように、コアまたはプロセッサのデコードハードウェア／ソフトウェアによってコアとプロセッサとはしばしばＩＳＡに関連付けられていてよい（認識された命令の定義）。

一実施形態では、モニタモジュール３０５が、ネイティブのＯＯＯコア３０１においてネイティブプログラムコード３２５の実行を監視して、この監視によって、モジュール３０５は、プログラムコード３２５のホットな部分／領域３２７を特定する。モニタモジュールは、ハードウェア、ソフトウェア、またはこれらの組み合わせからなっていてよい。一実施形態では、モニタモジュール３０５は、実行を監視するハードウェアを含む。一例では、ハードウェアが、マイクロアーキテクチャおよび／またはアーキテクチャフックを含んで（たとえば、リタイヤプッシュアウトを計測するためのリタイヤプッシュアウト・タグ／カウンタ、命令の数をカウントするための命令カウンタ、実行の長さ全体を計測するための全体トレース実行計測論理、および／または、コードセクションが実行された回数をカウントするための反復カウンタ等）、コード３２５の実行中のパフォーマンス電力メトリックを決定してよい。このタイプのハードウェアは、集積回路／プロセッサの任意の部分（たとえばアウトオブオーダコア３０１内、インオーダコア３０２内、および、ＯＯＯプロセッサコア３０１にもインオーダプロセッサコア３０２にも含まれていない集積回路の非関連部分）に位置させてよい。

別の実施形態では、モニタモジュール３０５が、実行されると、プログラムコード３２５の実行を監視して、プログラムコード３２５のホットな領域３２７を特定するソフトウェア（たとえばモニタコード）を含む。図示した例では、プロセッサ３００が、格納構造（たとえば読み取り専用（ＲＯＭ）構造、プログラム可能論理等）を含むことで、実行されると監視を行わせるコード、マイクロコード、または機械コードを保持する。しかし監視コードは、コア３０１、３０２に関連付けられている任意の機械可読媒体に格納することもできる。実行という用語は、単に従来の実行ユニットによる実行に限られず、プロセッサ３００に関連付けられている他のハードウェアまたはプログラム可能論理を含む（たとえば、ファームウェアでのマイクロコードの実行）。ここでは、実行される監視コードは、ハードウェアが計測可能な反復（recurrence）、電力、および、パフォーマンスメトリックの同じ監視を実行することができる。

一例として、監視ハードウェアおよび／またはコードが、プログラムコードのコードセクションの反復パターンを追跡／判断する。簡単な例として、データ構造が、コードセクションに対する参照（コード領域３２７；たとえば命令アドレス）を、命令アドレス／コードセクションがコア３０１で実行された回数のカウントに関連付ける。ここでカウントは、絶対カウント（総カウント）または一時的カウント（単位時間当たりのカウント）に関連付けられていてよい。

一実施形態では、モニタモジュール３０５が、プログラムコード３２５のホットな部分３２７を特定／検知するよう適合されている。モニタモジュール３０５は、一例では、ＯＯＯプロセッサコア３０１における実行中にプログラムコード３２５のホットな部分３２７の１以上のパフォーマンスメトリックを計測する。そしてモジュール３０５は、閾値未満のＯＯＯプロセッサコアのパフォーマンスメトリックに応じて、プログラムコード３２５のホットな領域３２７を特定する。包括的ではなく、例であるパフォーマンスメトリックのリストには、命令リタイヤプッシュアウト、実行された命令数、コード領域の実行にかかる時間、コード領域が遭遇された／実行された回数、コード領域の実行中に消費された電力量、コード領域の実行中の様々な電力状態で消費される時間、コードセグメントに実行中の熱密度などが含まれる。

これら例の１つを利用して、ＯＯＯコア３０１がプログラムコード３２５を実行すると仮定する。監視コードは、プログラムコード３２５の領域がコア３０１上で実行される回数を判断するために実行される。一実施形態で、カウントが閾値になる、またはこれを超えると、モニタモジュール３０５は、この領域３２７がホットコードであると特定／判断する。３の閾値が利用される場合、コア３０２で実行されている監視コードが、コア３０１で３度、再実行されたホットな領域３２７を検知して、領域３２７が、コードのホットな領域であると特定される。反復パターンを判断する具体例から推定して（extrapolate）、同様のプロセス（カウント、閾値に対する比較、および特定）が、計測されたパフォーマンスメトリックのいずれかに利用可能であることを示すことができる。さらに、パフォーマンスメトリックの判断は簡単なカウントに限られず、コア、プロセッサ、またはコンピュータシステムにおける実行または節電パフォーマンスを判断する任意の公知のアルゴリズムが含まれてよい。

しかし、プログラムコード３２５内でホットな領域３２７を特定することは、動的なパフォーマンス監視に限られない。この代わりに、コンパイラまたは静的プログラム分析を利用して、インオーダコア３０２の実行により適している可能性のあるコードセクションを判断することもできる。たとえば、プログラム分析によって、ホットな領域３２７が複数回再実行される可能性がある場合を想定する。この発見に応じて、コンパイラまたはユーザは、ホットコードとしてコードのセクションを特定する命令またはデマケーションを挿入してよい。したがい、コア３０１のデコーダがこの命令に遭遇すると、この領域３２７が、コア３０２で実行されるべきホットコードであると認識する。一部の実施形態では、ユーザが、深くプログラムを分析するのではなく、自身のプログラムの知識に基づいてコードのこの領域を特定する。

一実施形態では、領域３２７をホットとして特定すると、コード３２７が、最適化／変換モジュール３１０によって最適化され、または変換されて、最適化されたホットコード３０４が得られる。モニタモジュール３０５のオペレーション同様に、最適化モジュール３１０も、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせで実装されてよい。たとえば、変換および／または最適化コードは、コア３０２、コア３０１、またはプロセッサ３００に関連付けられている構造に格納されてよい。例示すると、バイナリ変換コードが、コア３０２に関連付けられているファームウェアに格納されている。バイナリ変換コードは、実行されると、コア３０１のネイティブフォーマットからのホットな領域３２７を、コア３０２のフォーマットに変換する。変換は、ＩＳＡの間またはその他のフォーマットの間で行われてよく、一方で、最適化には、実行のためにコードを最適化する任意の公知の方法（たとえば、ＯＯＯコア３０１のパラレル実行から、コア３０２におけるシリアル実行に、またはこの逆にコードを最適化する公知の技術）が含まれてよい。

しかし、ファームウェアのバイナリ変換コードの利用は、純粋に例であり、任意の変換コードまたは最適化コードを、コンピュータの任意の場所に保持することができる（たとえばコア３０２のマイクロコード、または、システムメモリの通常のプログラムコード）。そして、最適化コードは、任意の方法で実行されて、ホットな領域３２７を変換、または最適化して、最適化されたホットコード３０４を得ることができる。実際、コアのためのコードを変換または最適化する任意の公知の方法または装置（たとえば現行のソフトウェア管理されているプロセッサにおけるコード変換のための公知の方法または装置）を利用することができる。

ソフトウェア、ファームウェア、ハードウェア、またはこれらの組み合わせのいずれを利用するにしても、変換は静的または動的に実行することができる。実際、監視がランタイム中に動的に、または実行前に静的に実行可能であるのと同様に、変換および最適化も実行することができる。コンパイラまたはユーザがホットな領域３２７を特定する例では、最適化および変換が、その時点で行われてよい（実行前）。ここで、ホットコード識別子命令を利用して、ホットコード領域３２７の特定と、最適化／変換されたコード３０４の位置の特定の両方を行うことができる。しかし、セクション３２７が実行前または実行中ｎホットコードとして特定されたか否かに関わらず、一部の実施形態では、最適化および変換が動的に行われる（ランタイム中に）。

一実施形態では、ホットな領域３２７は、他の実行とパラレルに最適化／変換される。一例では、コア３０２は、領域３２７のコア３０１の実行とパラレルに最適化コードの実行を開始する。ここで、モニタモジュール３０５は、コア３０１のホットコード領域３２７の実行を検知して、最適化がコア３０２で行われるようにする。ホットな領域３２７からのさらなる命令がコア３０１でまだ行われている間に、コア３０２は最適化を開始する。この結果、コア３０２は、本質的にホットコード３２７を、コア３０１におけるホットコード３２７の実行とパラレルに最適化する。別の例では、コア３０１は、プログラムコード３２５の他のセクションを実行し、または、ホットコード３２７のコア３０２の最適化とパラレルに他の排他的なコードを実行する。別の実施形態では、ホットな領域３２７の最適化をシリアルに行う。たとえば、コア３０１はホットな領域３２７を実行して、次に、コア３０１または３０２が、ホットコード領域３２７を最適化する。

一実施形態では、コード３２７が、元のメモリ位置に格納されており、オンザフライでコア３０２によって変換される。しかしほとんどの場合、コードセクション全体を時刻前に変換／最適化するほうが効率がよい。この結果、最適化／変換モジュール３１０がコア（たとえばコア３０２）のためのコードを最適化した後に、最適化されたホットコード３０４を別の場所に格納しておく。最適化されたホットコード３０４のための他の位置は、メモリの別の位置（たとえば、ホーム、システムメモリ位置）であってよい。しかし、ホットコード３２７は、頻繁な実行に関連付けられている場合も多いので、最適化されたバージョン３０４はなるべくコア３０２に近い位置に置いておくほうが有利だと思われる。したがって、示されている実施形態では、コア３０３が、最適化されたホットコード３０４を保持しておくためのコードキャッシュ３０３を含んでいる。コードキャッシュ３０３は、コア３０２における別のキャッシュ構造、コア３０２の共有命令またはデータキャッシュ等の共有キャッシュ構造、または、コア３０２に関連付けられている他の汎用格納構造であってよい。

モニタモジュール３０５の説明に戻ると、ホットコード領域３２７に遭遇する一実施形態は、コードセクションに関連付けられている命令アドレスを参照するプログラムカウンタを含む。図示しているように、マッピングモジュール３１５が、最適化されたホットコードへの参照３１７と関連付けられているコード領域への参照（たとえば命令アドレス）を保持する。本質的には、マッピングモジュール３１５のエントリが、ホットコード領域３２７を、その最適化されたバージョン（最適化されたホットコード３０４）に関連付ける。一例では、参照３１６が、ホットな領域３２７に関連付けられているアドレス（命令アドレス等を含む。このシナリオでは、コア３０１がマッピングモジュール３１５のフィールド３１６に維持されている命令アドレスに遭遇すると（プログラムカウンタがこれを指し示すと）、モニタモジュール３０５が、ホットな領域３２７に遭遇して、コア３０２で実行されることを示す。協力モジュール３２０は、上で簡単に説明しており、後で詳述するが、次に、データおよび／またはコンテキストの、実行のためのコア３０２への移動を促す。

上述した例におけるホットな領域３２７に遭遇した、またはコア３０２で実行されるという判断は、参照３１６に対するもののみである。次にフィールド３１７のフィールド３１６への関連付けを利用することで、領域３２７の最適化されたホットコードバージョン３０４がどこに位置しているかを迅速に判断することができる。この結果、フィールド３１７は、最適化されたホットコード３０４の位置に対するいずれかの参照を含んでよい。これらの参照のいくつかの簡単な例には、最適化されたコード３０４を維持するコードキャッシュ３０３のエントリのアドレス、コードキャッシュ３０３の最初から、最適化されたホットコードを維持しているエントリ３０４へのオフセット、および、エントリ３０４に関連付けられている物理的またはリニアアドレスが含まれる。マッピングモジュール３１５は、簡単なテーブル構造で示されており、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせで実装および／または維持されてよい。しかし、ある位置を別の位置に関連づけるための任意の公知の方法を、ホットコード３２７をその最適化されたバージョンに関連付けるために利用することができる。

特に例示はしてないが、モニタモジュール３０５の部分と、マッピングモジュール３１５とを組み合わせて、ネイティブコード３２７をコア３０１で実行するのではなく、最適化されたホットコード３０４をコア３０２で実行することを示すトリガモジュールが形成される。一例では、コア３０１のプログラムカウンタが次の命令アドレスに移動されると、トリガハードウェアが、マッピングハードウェアテーブル３１５に格納されている参照との対照で、そのアドレスをチェックする。ここで、プログラムカウンタが、フィールド３１６に維持されているコード領域３２７を参照する命令アドレスを指し示していると想定する。次に、トリガハードウェアが、マッピングテーブル３１５のエントリに基づいて、コード領域３２７のための最適化されたコード領域３０４が存在していることを示す。この結果、コア３０１のコード領域３２７の実行を無視することができる（最適化されたバージョンが既に存在しており、コア３０２で実行されるから）。

一実施形態では、コア３０１が、コア３０２が最適化されたコードの実行を完了するまで、実行を停止する（ストップする、または、低電力状態に遷移する）。しかし、これは、プロセッサ３００の処理容量の完全利用にならない場合もある。したがって別の実施形態では、最適化されたホットコード３０４がコア３０２で実行されている間に、コア３０１が、別のソフトウェアスレッド（プログラムコード３２５以外のコード）の実行をインタリーブする。また別の例では、コア３０１が、投機的にプログラムコード３２５の他の部分を実行してよく、これは、本質的に、実行のランアヘッドヘルパスレッド（run-ahead helper thread）を実行したり、または、コード領域３２７に依存しないコード３２５の他の部分をアウトオブオーダで実行したりする。

協力モジュール３２０は、一実施形態では、コア３０１、３０２の間に協力機能を提供する。一番簡単な例では、協力モジュール３２０が、情報を移すためのコア３０１、３０２の間のインターコネクトを含んでいる。しかし別の実施形態では、協力モジュールが、上述した協力を促すために、個々のコア専用であってもこれらの間で共有されていてもよい他のハードウェアを含んでいる。たとえばコア３０２は、コア３０１から３０２へのレジスタ状態の完全なコンテキストスイッチが、最適化されたホットコード３０４がコア３０２で実行されているときに実行される必要がないように、コア３０１のシャドウレジスタファイルを共有してもよい。この代わりに、コア３０２が、この例のシャドウレジスタファイルに直接アクセスできる。しかし協力モジュールは、共有構造および／またはインターコネクトのみに限定はされない。実際、協力モジュール３２０は、レジスタ、格納構造、および両方のコア３０１、３０２のバッファに対して直接読み書きアクセスを提供するために、ハードウェア、ファームウェア、ソフトウェア、またはこれらの組み合わせを含んでよい。この結果、協力モジュール３２０は、一実施形態では、コア３０１からコア３０２への最適化されたホットコードの実行に必要なデータ／レジスタ値を移すことができる。そして、コア３０２からコア３０１に結果を戻して、後で、コア３０１で適切に実行させることもできる。

モニタモジュール３０５は、主に、ネイティブコア３０１での実行監視を例にとって説明されたが、一実施形態では、モニタモジュール３０５が、コア３０２における最適化されたコードの実行を監視することもできる。この結果、モニタモジュール３０５は、コア３０２での最適化されたバージョン３０４のパフォーマンスと、コア３０１のコードセクション３２７のパフォーマンスとを比較することができる。さらに、コア３０２のパフォーマンスがコア３０１のパフォーマンスより低い場合、または、コア３０２におけるパフォーマンス利得が、電力消費の増加に比べて小さい場合には、領域３２７をホットコードとして特定するための決定を逆にしてよい。一例では、この決定を示すマッピングモジュール３１５のエントリが割り当て解除されたり無効化されたりして、次にコア３０１がホットコード３２７に遭遇したときに、モニタモジュール３０５が、参照３１６を検知せず、領域３２７の最適化されたホットコードバージョンがコア３０２で実行されるべきであると示さないようにする。本質的には、逆の決定によって、前に特定された領域３２７が、アウトオブオーダコア３０１に戻される。

このパフォーマンス比較をさらに示す具体例として、コード領域３２７が、高い反復パターンと高い命令実行カウントに基づいて、ホットコードとして特定されると想定する。この結果、コード３２７が、コア３０２に存在しているバイナリ変換コードにより最適化され、最適化されたコード３０４が得られる。最適化されたコード３０４をコードキャッシュ３０３に格納するとき、マッピングテーブル３１５のエントリを作成して、コード領域３２７を、最適化されたバージョン３０４に関連付ける。コア３０１が、次に、フィールド３１６の参照に合致する参照に遭遇すると、最適化されたコード３０４の実行が、コア３０２でトリガされる（コア３０１のコード領域３２７で実行される代わりに）。協力モジュールは、転送、共有、またはコンテキストスイッチによって、コア３０１からコア３０２に適切な値を提供する点に留意されたい。コア３０２がホットコード３０４を実行している間に、同じパフォーマンスメトリック（命令実行カウント）をモニタモジュール３０５によって追跡する。命令実行カウントがコア３０１で実行されたコード領域３２７未満である場合、領域３２７をホットコードとして特定する現状維持を将来的も続ける。しかし、コア３０２での命令実行カウントのほうが長い場合、または顕著な電力増加が検知された場合には、上述したように、領域３２７をホットコードとして特定する判断を逆にすることができる。

コア３０１および３０２の間に通信を提供するのに加えて、協力モジュール３２０は、さらに、それぞれ異なるタイプの複数のコアを管理する他の特徴部を含んでよい。第１の例として、電力マネージャが、両方のコア３０１および３０２が同時に最大電力で動作しないようにする電力アルゴリズムを実装する。しかしこの例は純粋な例である。他の電力アルゴリズムでこのような最大のオペレーションをさせることもできる。電力について考えなければならない別のこととして、コア３０２が、コア３０１における実行監視中に、最大を下回る電力状態に存在している（低電力状態）場合もある、ということがある。たとえば、コア３０１が、自身の監視を実行するメカニズムに関連付けられている場合には、コア３０２は、実行するべきコードの最適化されたバージョンが得られるまでは、完全に電源が入った（powered up）状態にする必要はない。この結果、実行に必要となるまでは、コア３０２を停止させることで潜在的に節電することができるようになる。逆に、コア３０２が最適なホットコードを実行している間は、コア３０１への電力供給を停止させてよい（たとえばＡＣＰＩ低電力状態またはスリープ状態といった、最大未満の電力状態にする）。

コア間を動的に実行切り替えするときに、（１）コードの任意のセグメントのために最も適切なコアをタイムリー且つ正確に予測すること、および（２）コア間で実行を効率よく移動させること、という２つの課題がある。

一実施形態では、第１のコアでのプログラム実行が（たとえば、コード領域で分析されるＩＬＰに基づいて）ランタイムソフトウェアおよび／またはハードウェアにより特定されてよく、次に、現在のコアのパフォーマンスメトリックおよび／または統計データを、モニタモジュール３０５で継続的に収集して、プログラムコードの実行を第２のコアにスイッチするべきときを予測する。この方法は図４に示されている。この方法は、１つのコアからのデータを利用して、他のコアのパフォーマンスを予測するので、一実施形態では、この方法は「シングルコア予測」アルゴリズムと称される。

図４に戻ると、第１のタイプの第１のコア（アウトオブオーダコア等）と、第２のタイプの第２のコア（インオーダコア等）との間でコードを分配して、最大のパフォーマンスおよび節電効果を達成するための方法４００のフロー図の一実施形態が示されている。図４のフローは、実質的にシリアルで描かれているが、フローは、異なる順序で実施されても、パラレルに実施されてもよい。さらにフローそれぞれを、ハードウェア、ファームウェアを利用して、またはプログラムコードに実行によって実施されてもよい。

プロセッサのアウトオブオーダ（ＯＯＯ）プロセッサコアでのプログラムコードの実行を監視する。一実施形態では、プログラムコードに対する言及は、（１）動的であっても静的であっても、他のプログラムコードをコンパイルするためのコンパイラプログラムの実行、（２）オペレーティングシステム、ハイパーバイザ、アプリケーションコードその他のソフトウェアプログラム等のメインプログラムの実行、（３）メインプログラムコードに関連付けられている、ライブラリ等の他のプログラムコードの実行、（４）メインプログラムに直接関係しなくてよい他のプログラムコード（たとえばヘルパースレッドその他のタスク）、または（５）これらの組み合わせのことであってよい。

コンパイラは、対象テキスト／コードにソーステキスト／コードを変換するプログラムまたは一組のプログラムを含んでよい。通常は、コンパイラによるプログラム／アプリケーションコードのコンパイルは、複数フェーズで行われ、高レベルプログラミング言語コードを、低レベルマシンまたはアセンブリ言語コードに変換するように渡すことができる。しかし、シングルパスコンパイラは、単純なコンパイルに利用することもできる。コンパイラは、任意の公知のコンパイル技術を利用して、任意の公知のコンパイラオペレーションを行うことができる（語彙分析、前処理パース、意味分析、コード生成、コード変換、およびコードの最適化等）。

より大きなコンパイラが、しばしば、複数のフェーズを含むことができるが、（１）フロントエンド（一般的に構文処理、意味処理、および一部の変換／最適化を行ってよい場所）、（２）バックエンド（一般的に、分析、変換、最適化、およびコード生成を行ってよい場所）という２つの一般的なフェーズ内に含まれている。一部のコンパイラは、ミドルエンドについて言及しているが、このミドルエンドは、コンパイラのフロントエンドとバックエンドとの間の境界の曖昧なところを表している。この結果、挿入、関連付け、生成、その他のコンパイラのオペレーションに対する言及は、上述したフェーズまたはパスのいずれか、および、コンパイラの任意の他の公知のフレーズまたはパスで行われてよい。

一実施形態では、モニタモジュール３０５のプログラムコードの実行監視が、プログラムコード内でのコードセグメント／領域の実行回数を追跡することを含む。コード領域は、命令／コードを分類する任意の公知の方法で決定されてよい。一例として、コードセクションに関連付けられている命令アドレスがＯＯＯコアのプログラムカウンタにより参照されるたびに、反復カウントを増分させる。コードセクションの反復カウントが閾値を超えると、一実施形態では、このコードセクションをホットコードとして特定する。

反復パターンの判断に関連して、または別個に、プログラムコードの実行監視には、コードセクションに関するパフォーマンスメトリックの決定／追跡が含まれてよい。上述したように、例であるパフォーマンスメトリックには、命令リタイヤプッシュアウト、実行された命令数、コード領域の実行にかかる時間、コード領域が遭遇された／実行された回数、コード領域の実行中に消費された電力量、コード領域の実行中の様々な電力状態で消費される時間、コードセグメントに実行中の熱密度が含まれてよい。しかし、プロセッサ実行に関する任意の公知のメトリックまたはメトリックの組み合わせが、プログラムコードの実行中に監視されてよい。

ブロック４０２で、プログラムコードを第１のコアで実行してよい。一実施形態では、第１のコアが、狭帯域のアウトオブオーダコア等の第１のタイプであってよい。ブロック４０４で、第１のコアがプログラムコードを実行する際に、第１のコアのパフォーマンスを監視してよい。ブロック４０６で、パフォーマンスの統計データを収集してよい。一実施形態では、統計データには、分岐ミス率、キャッシュミス率等が含まれてよい。一実施形態では、パフォーマンスの監視および統計データの収集が、モニタモジュール３０５により実行されてよい。ブロック４０８で、第２のコアにおけるプログラムコードの実行のパフォーマンスが、第１のコアにおけるプログラムコードの実行のパフォーマンスおよび統計データに少なくとも一部基づいて、予測されてよい。一実施形態では、第２のコードが、第２のタイプであってよい（たとえば広帯域のインオーダコア）。代わりに、第１のタイプが、広帯域のインオーダコアであってよく、第２のタイプが、狭帯域のアウトオブオーダコアであってよい。一実施形態では、予測が、「予測＿パフォーマンス」と称される関数として実装されてよい。ブロック４１０で、第２のコアによるプログラムコードの実行について予測されたパフォーマンスが、第１のコアによるプログラムコードの実行について監視されたパフォーマンスよりも良好な場合には、以下の動作を実行してよい。

ブロック４１２で、第２のコアを、低電力または「スリープ」状態から立ち上げてよい（powered up）。立ち上げ中に、第１のコアが、プログラム実行を続ける。ブロック４１４で、プログラムコードの実行が、第１のコアから第２のコアにスイッチされてよい。ブロック４１６で、第１のコアが、スリープ状態へと電力を落とされる（powered down）。第２のコアの予測されたパフォーマンスが第１のコアのものよりよくない場合には、第１のコアにおけるプログラムコードの実行を続けてよい。後で方法を反復するときに、方法における第１のコアおよび第２のコアの位置を交換してもよい（たとえば、第２のコアがまず実行されて、第２のコアのパフォーマンスが監視され、第２のコアの統計データを収集して、第１のコアのパフォーマンスを予測する、等が行われてよい）。一実施形態では、ブロック４０４から４１６が、コード分配モジュール２１０により実行されてよい。

予測＿パフォーマンス関数（コア数、パフォーマンス＿コア１、統計データ＿コア１）で、現在のコアの実行パフォーマンスおよび統計データである、パフォーマンス＿コア１、および統計データ＿コア１を利用して、第２のコアにおける実行のパフォーマンスを予測する。予測されたパフォーマンスが現在のコアよりも高い場合、実行を他のコアに切り替える。この方法は、現在のコアのパフォーマンス情報を利用して、他のコアのパフォーマンスを予測することができるという想定に基づいている。直感的には、過度のキャッシュ／分岐ミスのあるプログラムの実行は、後の命令をアウトオブオーダで実行すると、ミスのレイテンシーを隠すことができることから、狭帯域のアウトオブオーダのコアでのパフォーマンスのほうが良好になるはずである。他方で、高い命令レベルのパラレリズム（ＩＬＰ）および低キャッシュ／分岐ミスのプログラムは、実行帯域幅が高いことから、広帯域のインオーダコアでより効率的に実行されるはずである。

一実施形態では、予測＿パフォーマンス関数を定義するためには、まずｃ１、...、ｃｎというｎ個のコードを第１のコアおよび第２のコアの両方で実行して、２つのコアにおけるそれぞれのパフォーマンス情報（ｐ１１、ｐ１２、...、ｐ１ｎ）（ｐ２１、ｐ２２、...、ｐ２ｎ）および、統計データ（ｓ１１、ｓ１２、...、ｓ１ｎ）（ｓ２１、ｓ２２、...、ｓ２ｎ）を収集してよい。そして、最適に適合する関数Ｆを見つけるための１つのやり方としては、（Ｆ（ｐ１１、ｓ１１）、Ｆ（ｐ１２、ｓ１２）、...、Ｆ（ｐ１ｎ、ｓ１ｎ）、−（ｐ２１、ｐ２２、...、ｐ２ｎ）およびＦ（Ｆ（ｐ２１、ｓ２１）、Ｆ（ｐ２２、ｓ２２）、...、Ｆ（ｐ２ｎ、ｓ２ｎ）、−（ｐ１１、ｐ１２、...、ｐ１ｎ）が最小限になるものを見つけるやり方がある。最適な適合の標準誤差が小さい場合には、Ｆを、予測＿パフォーマンスの関数として利用することができる。しかし標準誤差が大きい場合には、予測精度を高めるために、より多くのパフォーマンスパラメータを見つける必要があるだろう。

シングルコアの予測法の１つの利点は、決定に際して他のコアに関するパフォーマンスおよび電力オーバヘッドを考慮せずに、現在のコア実行統計データのみを利用して、他のコアのパフォーマンスを予測することができる点である。しかしこの方法は、２つのコアのパフォーマンスが密に関連しあっていることが前提である。一部の環境／構成においては、２つのコアのパフォーマンスが、緩い相関性しか有さず、良好な適合関数が存在しない場合もある。したがって、この場合は、より一般的な方法をとると好適だろう。

別の実施形態では、デュアルコア予測方法により、短期間に２つのコアに観察されるパフォーマンス情報を利用して、コアの切り替えが予測される。具体的に、「予測」は、２つのコアのパフォーマンスをサンプリングおよび比較するために定期的な間隔で実行されて、異なるコアに実行をスイッチすべきかを決定してよい。各予測は、２つのコアのスイッチに関している。つまり、第１のスイッチは、他のコアからパフォーマンス情報を取得するために行われ、第２のスイッチは、他のコアのパフォーマンスが、第１のコアのものより劣るために、実行を第１のコアに戻すべき場合に行われる。第１のコアのスイッチは、他のコアを立ち上げて、実行のためにそのマイクロアーキテクチャ状態をウォームアップして、第２のコアのスイッチは、コアの電力を落とすことだけに関している。

コアのスイッチオーバヘッドを低減させるために、予測は２つのオペレーション（つまり「継続用の予測（Ｐｃｏｎｔ）」オペレーションおよび「スイッチのための予測（Ｐｓｗｉｔ）」に分けられてよい。Ｐｃｏｎｔオペレーションは、現在のコアで収集されたパフォーマンス情報を、２つのコアの前のパフォーマンス情報と比較して、実行を現在のコアで続けるべきかを判断する。Ｐｃｏｎｔオペレーションが、実行を現在のコアで続けるべきではないと予測している場合には、Ｐｓｗｉｔオペレーションにより、他のコアを起動して、他のコアを短期間実行させ、２つのコアのパフォーマンス情報を比較して、他のコアに実行を移すべきかを判断する。Ｐｃｏｎｔが同じコアで実行され続ける期間が長くなりすぎないように、パラメータＫを導入して、ＰｓｗｉｔオペレーションがＫを超える回数、立て続けに（in a row）省かれないようにする。さらに、Ｐｓｗｉｔオペレーションを省くたびに、前のパフォーマンスを、インフレーション係数でインフレーションして、次のＰｃｏｎｔ期間で、Ｐｓｗｉｔオペレーションを省くことが困難になるようにしてよい。

デュアルコア予測プロセス５００が図５に示されている。一実施形態では、Ｓが、サンプリング間隔であり（たとえば予測の間のサイクル数）、Ｍが各コアでのパフォーマンスを収集するためのサンプル長（たとえばサイクル数）であり、ＰＵが、第２のコアを立ち上げるためのサイクル数であり、ＩＰＣが、サイクルごとの命令数であり、Ｋは、最大継続数（Ｋは自然数である）であり、Ｎは、継続数（最初は０に設定されている）であり、Ｐｒｅｖ＿ＩＰＣが、前のＩＰＣ（最初はＭＡＸ＿ＦＬＯＡＴに設定されている）である。一実施形態では、Ｓ、Ｍ、ＰＵ、Ｋ、およびインフレーション係数が、適切な値に設定されていてよい。

ブロック５０２で、プログラムコードが、Ｓ個のサイクルのサンプリング間隔分、第１のコアで実行されてよい。一実施形態では、第１のコアが、第１のタイプであってよい（たとえば狭帯域のアウトオブオーダコア）。ブロック５０４で、プログラムコード実行開始からＳ+Ｍサイクルが終わる前に、ＰＵサイクル分、第２のコアの立ち上げを、信号で指示してよい。一実施形態では、第２のコアが、第２のタイプであってよい（たとえば広帯域のインオーダコア）。この代わりに、第１のタイプが、広帯域のインオーダコアであって、第２のタイプが、狭帯域のアウトオブオーダコアであってのよい。ブロック５０６で、第１のコア（ＩＰＣ１）のサイクルごとの命令数を、Ｍ個のサイクルの間収集してよい。一実施形態では、パフォーマンスの監視と、統計データの収集とを、モニタモジュール３０５またはコード分配モジュール２１０のいずれかで実行してよい。

次に、第１のコア（Ｐｃｏｎｔ）での継続実行の予測を以下のように行ってよい。ブロック５０８で、継続数Ｎが、最大継続数Ｋを下回る場合であって、第１のコアＩＰＣ１のサイクルごとの命令数が、サイクルごとの前の命令数より大きい場合（Ｐｒｅｖ＿ＩＰＣであり、最初は最大値に設定されている）には、ブロック５１０、５１２、および５１４を実行してよい。この場合には、第１のコアから第２のコアへのスイッチを行わない。ブロック５１０で、第２のコアの電力を落とすよう信号で指示してよい。ブロック５１２で、サイクルごとの前の命令数（Ｐｒｅｖ＿ＩＰＣ）が、Ｐｒｅｖ＿ＩＰＣに、インフレーション係数を乗じた数に設定されてよい。処理は、プログラムコードを第１のコアで継続実行して継続される。

継続数Ｎが、最大継続数Ｋ以下である場合、または、第１のコアのサイクルごとの命令数（ＩＰＣ１）が、サイクルごとの前の命令数（Ｐｒｅｖ＿ＩＰＣ）以下である場合には（ブロック５０８）、ブロック５１６、５１８、および５２０を実行してよい。この場合には、第１のコアから第２のコアへのスイッチを行ってよい。次に、第１のコアから第２のコアへの実行のスイッチのための予測（Ｐｓｗｉｔ）を以下のように行ってよい。ブロック５１６で、カウンタＮが０に設定されてよい。ブロック５１８で、プログラムコードの実行を第１のコアから第２のコアにスイッチしてよく、第２のコアのサイクルごとの命令数（ＩＰＣ２）を収集してよい。次に、チェックを行って、スイッチが意味のあるものであったかを検証する。

ブロック５２０で第２のコアのサイクルごとの命令数（ＩＰＣ２）が、第１のコアのサイクルごとの命令数（ＩＰＣ１）未満である場合に、プログラムコードの実行を第２のコアから第１のコアにスイッチして戻す（ブロック５２２）。サイクルごとの命令数以外の別のパフォーマンスメトリックを利用する場合に、第２のコアにおけるパフォーマンスが第１のコアにおけるパフォーマンスより良くない場合には、プログラムコードの実行が、第２のコアから第１のコアにスイッチして戻されてよい。第２のコアの電力を落とすよう、次に信号で指示してよい（ブロック５２４）。しかし、ブロック５２０で、第２のコアのサイクルごとの命令数（ＩＰＣ２）が、第１のコアのサイクルごとの命令数（ＩＰＣ１）未満でない場合には、コアのスイッチが意味のあるものであることになる。サイクルごとの命令数以外の別のパフォーマンスメトリックを利用する場合に、第２のコアにおけるパフォーマンスが第１のコアにおけるパフォーマンス以上である場合には、コアのスイッチが意味のあるものであることになる。ブロック５２８で、第１のコアの電力を落とすよう、信号で指示してよい。いずれの場合であっても、一実施形態では処理がブロック５３０で、サイクルごとの前の命令数（Ｐｒｅｖ＿ＩＰＣ）を、ＩＰＣ値の平均値（ＩＰＣ１＋ＩＰＣ２／２）に設定して続けられる。ここでは算術平均を平均値として利用しているが、幾何平均、調和平均、およびその他のいずれの平均を利用して、２つのＩＰＣ値の平均を提示してもよい。このようにして、第１のコアの電力が落とされた状態で、第２のコアに処理を行うことができる。後での方法の反復において、方法における第１のコアおよび第２のコアの位置を交換してもよい（たとえば、第２のコアがまずＳサイクルについて実行されて、第１のコアの立ち上げを信号で指示して、第２のコアのパフォーマンスをＭ個のサイクル分監視して、第２のコアについての統計データを収集する、など）。一実施形態では、少なくともブロック５０４から５３０までを、コード分配モジュール２１０により実行してよい。

コアのスイッチには、（１）低電力状態であってよい他のコアの起動、（２）ｘ８６レジスタ状態を他のコアに移す、（３）頻繁にアクセスされたデータを他のデータキャッシュに移す、（４）命令キャッシュ、分岐予測状態、および他のコアの他の状態をウォームアップする、といったいくつかのオーバヘッドが関係する。

他のコアを起動する（または立ち上げる）ときのレイテンシーは、他のコアの低電力状態に依存している。一部の実施形態では、コアが停電量Ｃ２状態にあるとき（つまり通常の動作出力の３０％までを消費するとき）、コアの電力を通常の動作速度（Ｃ０状態）にまで上げるためには、５０００サイクル程度が必要となるだろう。コアが、より深い電源停止状態（Ｃ６）にある場合には（つまり、動作電力の１０％未満を消費しているとき）、一実施形態では、再起動（wake up）するために２０万サイクル程度が必要となるだろう。立ち上げは時間がかかるが、他のコアの実行とパラレルに実行することができる。例えば、一実施形態では、第１のコアがＰｓｗｉｔ／Ｐｃｏｎｔ期間に入る前に、第１のコア（またはその他のモジュール）が、信号を第２のコアに送って、立ち上げを開始させてもよい。第１のコアの予測期間が終わるときには、第２のコアが既に立ち上がっており、プログラムコードの実行を続けることができてもよい。この早期に立ち上げる戦略をもってすれば、立ち上げのレイテンシーは、エネルギー消費量を増加させはするかもしれないが、コアのスイッチのレイテンシーにもパフォーマンスにも影響しない。

一実施形態では、レベル２（Ｌ２）キャッシュが２つのコアで共有されていても、データおよび命令キャッシュのウォームアップに１万サイクル程度かかる。さらに、現代のハイブリッド分岐予測器においては、分岐予測器をかなり急速にウォームアップすることができる。コアの立ち上げが、ＰＵサイクルかかり、分岐予測器およびＬ１キャッシュのウォームアップがＷＵサイクルかかると想定する。図６は、コアスイッチ動作とオーバヘッドとを示している。図６における時間の表示は例示にすぎず、様々な段階の間の実際の特定のタイミング関係を伝える意図は持たない点を理解されたい。第１のコア６０１がＰｃｏｎｔ期間に入る前に、第１のコアは、第２のコア６０２に立ち上がるよう信号で指示する（６０３）。第１のコアが自分のＰｃｏｎｔオペレーションを終了した後で、コアスイッチが必要となるかもしれないと判断すると、プログラムコード実行を第２のコア６０４にスイッチさせてよい。この時点では、第２のコアが既に立ち上がっており、ＷＵサイクル６０５分、ウォームアップを開始する。ウォームアップ期間の後に、第２のコアは短期間（たとえばＭサイクル）作動して、自身のパフォーマンスデータ６０６を収集する。ここで、第２のコアのパフォーマンスが第１のコアのパフォーマンスより良好なので、第２のコアが第１のコアに対して電力を落とすよう（ＰＤ）指示して６０７、第２のコアでの実行を続ける、と想定する。次のＰｃｏｎｔ期間の最後に近づくと、第２のコアは、第１のコアに立ち上がるよう信号で指示する６０８.第２のコアが自身のＰｃｏｎｔ期間を終えた後で、第２のコアが実行を継続すべきであると認識すると、第２のコアは第１のコアに対して、電力を落とすようして６０９、第２のコアでのプログラムコードの実行を続けるよう信号で指示する。

ネイティブコアを、異なる共同設計されたコアに連結させる結果、ここで説明する動的なコア選択技術を利用した場合に１つのアプリケーション内であっても、電力および実行の利点のうち最良のものが潜在的に得られる。例えば、アウトオブオーダコアおよびソフトウェア管理されているインオーダコアを利用すると、ソフトウェア管理されているコアでは非効率なコードが、アウトオブオーダコアに移される。またこの逆に、アウトオブオーダコアでは非効率なコードが、ソフトウェア管理されているコアに移される。ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせによって、ネイティブコードのパラレル実行、ホットコード検知、およびホットコード最適化を効率的に管理することができるようになり、且つ、複数のスレッドの個々のセクションを、アウトオブオーダおよびインオーダ共同設計コアの間で、パイプライン方式で効率よくインタリーブすることができるようになる。この結果、最大パフォーマンスが得られ、且つ、異なる電力効率技術（たとえば、一部の実装例で、インオーダコアにおける実行中に、アウトオブオーダコアを低電力状態に置く等）によってより良い電力パフォーマンスを達成することができる。

ここで利用するモジュールは、任意のハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせであってよい。別個に例示されているモジュール間の境界は、通常変化して、潜在的に重なっている場合もある。例えば第１および第２のモジュールは、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせを共有して、一方で、一部の独立したハードウェア、ソフトウェア、またはファームウェアを維持している可能性があってもよい。一実施形態では、論理という用語を利用する場合、ハードウェア（たとえばトランジスタ、レジスタ、またはその他の、プログラム可能な論理デバイス等のハードウェア）が含まれてよい。しかし別の実施形態では、論理にはさらに、ハードウェアと統合されたソフトウェアコードが含まれる（たとえばファームウェアまたはマイクロコード）。

ここで利用する値には、任意の公知の数、状態、論理状態、またはバイナリ論理状態の表現が含まれている。しばしば、論理レベル、論理値またはロジック値の利用は、１および０で表されることがあり、これらは単にバイナリ論理状態を表しているに過ぎない。たとえば１は、論理レベルがハイである場合を示し、０は、論理レベルがローである場合を示す。一実施形態では、記憶セル（たとえばトランジスタまたはフラッシュセル）が、１つの論理値または複数の論理値を維持することができる。しかし、コンピュータシステムでは値の他の表現を利用してきた。例えば十進数の１０は、二値法で１０１０で表され、１６進法でＡで表される。したがって、値は、コンピュータシステムが維持可能な情報の任意の表現形態を含む。

さらに、状態は、値または値のある部分によって表現されてよい。一例では、第１の値（たとえば論理「１」）は、デフォルトまたは初期状態を表してよく、第２の値（たとえば論理「０」）は、デフォルトではない状態を表してよい。加えて、リセットおよびセット（設定）という用語は、デフォルトと、更新された値または状態をそれぞれ示す。例えば、デフォルト値は、潜在的に、高い論理値（つまりリセット）を示し、更新された値は、潜在的に、低い論理値（つまりセット）を含む。値の任意の組み合わせを利用することで、任意の数の状態を表すことができる。

上述した方法、ハードウェア、ソフトウェア、ファームウェア、またはコードの実施形態は、処理エレメントが実行可能な機械可読媒体に格納されている命令またはコードにより実装されてよい。機械可読媒体は、機械（たとえばコンピュータまたは電子システム）が可読な形態で情報を提供（つまり格納および／または送信）することができる任意のメカニズムを含む。たとえば、機械可読媒体は、ランダムアクセスメモリ（ＲＡＭ）（たとえばスタティックＲＡＭ（ＳＲＡＭ）またはダイナミックＲＡＭ（ＤＲＡＭ））、ＲＯＭ，磁気または光学記憶媒体、フラッシュメモリ素子、電気記憶素子、光学記憶素子等を含む。

本明細書全体において、「１実施形態」または「１つの実施形態」という言い回しは、その実施形態で記載される特定の特徴、構造、または特性が、本発明の少なくとも１つの実施形態に含まれていることを示す。したがって「１実施形態」または「１つの実施形態」という言い回しが本明細書の随所にみられても、これらは必ずしも全てが同じ実施形態のことを意味しているわけではない。さらに、特定の特徴、構造、または特性は、１以上の実施形態において、任意の適切な方法で組み合わせることができる。

前述した明細書では、具体的な実施形態を参照しながら詳細な記載を行った。しかし、添付請求項に示されている本発明の広義の精神および範囲を逸脱せずに、様々な変形例および変更例が可能である。したがい、明細書および図面は、限定ではなく例示として受け取られたい。さらに、実施形態の前述した用途および例である他の用語は、必ずしも同じ実施形態または同じ例を示している場合ばかりではなく、異なる別個の実施形態のことである場合もあれば、同じ実施形態を示している場合もある。

Claims (30)

1. 異種マルチコア処理システムで動的にコアをスイッチする方法であって、
   前記異種マルチコア処理システムの第１のタイプの第１の処理コアでプログラムコードを実行する段階と、
   前記プログラムコードを実行する前記第１の処理コアのパフォーマンスを監視して、統計データを収集する段階と、
   前記第１の処理コアについての監視された前記パフォーマンスおよび収集された前記統計データに少なくとも一部基づいて、前記異種マルチコア処理システムの、前記第１のタイプと異なる第２のタイプの第２の処理コアで前記プログラムコードを実行する際のパフォーマンスを予測する段階と、
   予測された、前記第２の処理コアで前記プログラムコードを実行する際のパフォーマンスが、前記プログラムコードを実行する前記第１の処理コアのパフォーマンスよりも良好である場合には、前記プログラムコードの実行を、前記第１の処理コアから前記第２の処理コアにスイッチする段階と
   を備え、
   前記第２の処理コアのパフォーマンスを予測する段階は、
   複数のコードセグメントを、前記第１の処理コアおよび前記第２の処理コアの両方で実行する段階と、
   前記コードを実行している間に、前記第１の処理コアおよび前記第２の処理コアのそれぞれのパフォーマンス情報および統計データを収集する段階と、
   最良適合関数（best fit function）Ｆ（前記第１の処理コアのパフォーマンス情報および統計データ）と、前記第２の処理コアのパフォーマンスとの間の差が最小になるように前記Ｆを決定する段階と
   を有する、方法。
2. 予測された、前記第２の処理コアで前記プログラムコードを実行する際のパフォーマンスが、前記プログラムコードを実行する前記第１の処理コアのパフォーマンスよりも良好である場合には、前記第２の処理コアを、低電力状態から立ち上げる段階をさらに備える、請求項１に記載の方法。
3. 予測された、前記第２の処理コアで前記プログラムコードを実行する際のパフォーマンスが、前記プログラムコードを実行する前記第１の処理コアのパフォーマンスよりも良好である場合には、前記第１の処理コアを低電力状態に落とす段階をさらに備える、請求項１または２に記載の方法。
4. 前記第１の処理コアは、アウトオブオーダ処理コアを含み、前記第２の処理コアは、インオーダ処理コアを含む、請求項１から３のいずれか一項に記載の方法。
5. 前記第２の処理コアは、アウトオブオーダ処理コアを含み、前記第１の処理コアは、インオーダ処理コアを含む、請求項１から３のいずれか一項に記載の方法。
6. コンピュータに請求項１から５のいずれか一項に記載の方法を実行させるためのプログラム。
7. 集積回路を備える異種マルチコア処理システムであって、前記集積回路は、
   プログラムコードを実行する第１のタイプの第１の処理コアと、
   前記プログラムコードを実行する、前記第１のタイプとは異なる第２のタイプの第２の処理コアと、
   コード分配モジュールと
   を備え、
   前記コード分配モジュールは、
   前記プログラムコードを実行する前記第１の処理コアのパフォーマンスを監視して、統計データを収集して、前記第１の処理コアについての監視された前記パフォーマンスおよび収集された前記統計データに少なくとも一部基づいて、前記第２の処理コアで前記プログラムコードを実行する際のパフォーマンスを予測して、予測された、前記第２の処理コアで前記プログラムコードを実行する際のパフォーマンスが、前記プログラムコードを実行する前記第１の処理コアのパフォーマンスよりも良好である場合には、前記プログラムコードの実行を、前記第１の処理コアから前記第２の処理コアにスイッチし、
   前記第２の処理コアで前記プログラムコードを実行する際のパフォーマンスを予測することは、複数のコードセグメントを、前記第１の処理コアおよび前記第２の処理コアの両方で実行し、前記コードを実行している間に、前記第１の処理コアおよび前記第２の処理コアのそれぞれのパフォーマンス情報および統計データを収集し、最良適合関数（best fit function）Ｆ（前記第１の処理コアのパフォーマンス情報および統計データ）と、前記第２の処理コアのパフォーマンスとの間の差が最小になるように前記Ｆを決定することを含む、
   異種マルチコア処理システム。
8. 前記コード分配モジュールは、
   予測された、前記第２の処理コアで前記プログラムコードを実行する際のパフォーマンスが、前記プログラムコードを実行する前記第１の処理コアのパフォーマンスよりも良好である場合には、前記第２の処理コアを、低電力状態から立ち上げる、請求項７に記載の異種マルチコア処理システム。
9. 前記コード分配モジュールは、
   予測された、前記第２の処理コアで前記プログラムコードを実行する際のパフォーマンスが、前記プログラムコードを実行する前記第１の処理コアのパフォーマンスよりも良好である場合には、前記第１の処理コアを低電力状態に落とす、請求項７または８に記載の異種マルチコア処理システム。
10. 前記第１の処理コアは、アウトオブオーダ処理コアを含み、前記第２の処理コアは、インオーダ処理コアを含む、請求項７から９のいずれか一項に記載の異種マルチコア処理システム。
11. 前記第２の処理コアは、アウトオブオーダ処理コアを含み、前記第１の処理コアは、インオーダ処理コアを含む、請求項７から９のいずれか一項に記載の異種マルチコア処理システム。
12. 異種マルチコア処理システムで動的にコアをスイッチする方法であって、
    前記異種マルチコア処理システムの第１のタイプの第１の処理コアでプログラムコードを、第１の数のサイクルの間、実行する段階と、
    前記異種マルチコア処理システムの、前記第１のタイプと異なる第２のタイプの第２の処理コアの立ち上げを信号で指示する段階と、
    第２の数のサイクルの間、前記プログラムコードを実行する前記第１の処理コアの第１のパフォーマンスメトリックを収集する段階と、
    前記第１のパフォーマンスメトリックが、前に決定されたコアパフォーマンスメトリックより良好な場合には、前記第２の処理コアの電力を落とすよう信号で指示して、前記第１の処理コアで前記プログラムコードの実行を続け、前記第１のパフォーマンスメトリックが、前記前に決定されたコアパフォーマンスメトリックより良好ではない場合には、前記プログラムコードの実行を、前記第１の処理コアから前記第２の処理コアにスイッチして、第２の数のサイクルの間、前記プログラムコードを実行している前記第２の処理コアの第２のパフォーマンスメトリックを収集する段階と
    を備え、
    前記第２の処理コアの立ち上げを信号で指示する段階は、
    前記第１の数のサイクルと前記第２の数のサイクルの合計が終わる前に、第３の数のサイクルを立ち上げるよう信号で指示する段階を有する、方法。
13. 前記第１のパフォーマンスメトリックが、前記前に決定されたコアパフォーマンスメトリックより良好な場合には、前記前に決定されたコアパフォーマンスメトリックを、前記前に決定されたコアパフォーマンスメトリックを、インフレーション係数で乗算した値に設定する段階をさらに備える、請求項１２に記載の方法。
14. 前記第１の処理コアから前記第２の処理コアに、前記プログラムコードの実行を強制的にスイッチさせ、前記第２の数のサイクルの間、前記プログラムコードを実行する前記第２の処理コアの第２のパフォーマンスメトリックを、前記第１のパフォーマンスメトリックと前記前に決定されたコアパフォーマンスメトリックとをＫ回比較する毎に少なくとも１度、収集する段階をさらに備え、
    前記Ｋは自然数である、請求項１２または１３に記載の方法。
15. 異種マルチコア処理システムで動的にコアをスイッチする方法であって、
    前記異種マルチコア処理システムの第１のタイプの第１の処理コアでプログラムコードを、第１の数のサイクルの間、実行する段階と、
    前記異種マルチコア処理システムの、前記第１のタイプと異なる第２のタイプの第２の処理コアの立ち上げを信号で指示する段階と、
    第２の数のサイクルの間、前記プログラムコードを実行する前記第１の処理コアの第１のパフォーマンスメトリックを収集する段階と、
    前記第１のパフォーマンスメトリックが、前に決定されたコアパフォーマンスメトリックより良好な場合には、前記第２の処理コアの電力を落とすよう信号で指示して、前記第１の処理コアで前記プログラムコードの実行を続け、前記第１のパフォーマンスメトリックが、前記前に決定されたコアパフォーマンスメトリックより良好ではない場合には、前記プログラムコードの実行を、前記第１の処理コアから前記第２の処理コアにスイッチして、第２の数のサイクルの間、前記プログラムコードを実行している前記第２の処理コアの第２のパフォーマンスメトリックを収集する段階と
    を備え、
    前記第１のパフォーマンスメトリックが、前記前に決定されたコアパフォーマンスメトリックより良好な場合には、前記前に決定されたコアパフォーマンスメトリックを、前記前に決定されたコアパフォーマンスメトリックを、インフレーション係数で乗算した値に設定する段階をさらに備える、方法。
16. 異種マルチコア処理システムで動的にコアをスイッチする方法であって、
    前記異種マルチコア処理システムの第１のタイプの第１の処理コアでプログラムコードを、第１の数のサイクルの間、実行する段階と、
    前記異種マルチコア処理システムの、前記第１のタイプと異なる第２のタイプの第２の処理コアの立ち上げを信号で指示する段階と、
    第２の数のサイクルの間、前記プログラムコードを実行する前記第１の処理コアの第１のパフォーマンスメトリックを収集する段階と、
    前記第１のパフォーマンスメトリックが、前に決定されたコアパフォーマンスメトリックより良好な場合には、前記第２の処理コアの電力を落とすよう信号で指示して、前記第１の処理コアで前記プログラムコードの実行を続け、前記第１のパフォーマンスメトリックが、前記前に決定されたコアパフォーマンスメトリックより良好ではない場合には、前記プログラムコードの実行を、前記第１の処理コアから前記第２の処理コアにスイッチして、第２の数のサイクルの間、前記プログラムコードを実行している前記第２の処理コアの第２のパフォーマンスメトリックを収集する段階と
    を備え、
    前記第１の処理コアから前記第２の処理コアに、前記プログラムコードの実行を強制的にスイッチさせ、前記第２の数のサイクルの間、前記プログラムコードを実行する前記第２の処理コアの第２のパフォーマンスメトリックを、前記第１のパフォーマンスメトリックと前記前に決定されたコアパフォーマンスメトリックとをＫ回比較する毎に少なくとも１度、収集する段階をさらに備え、
    前記Ｋは自然数である、方法。
17. 前記第２のパフォーマンスメトリックが前記第１のパフォーマンスメトリックより良好ではない場合、前記プログラムコードの実行を、前記第２の処理コアから前記第１の処理コアにスイッチして戻し、前記第２の処理コアの電力を落とすよう信号で指示する段階をさらに備える、請求項１２から１６のいずれか一項に記載の方法。
18. 前記第２のパフォーマンスメトリックが前記第１のパフォーマンスメトリックより良好な場合、前記第１の処理コアの電力を落とすよう信号で指示し、前記前に決定されたコアパフォーマンスメトリックを、前記第１のパフォーマンスメトリックと前記第２のパフォーマンスメトリックとの平均に設定する段階をさらに備える、請求項１７に記載の方法。
19. 前記第１の処理コアは、アウトオブオーダ処理コアを含み、前記第２の処理コアは、インオーダ処理コアを含む、請求項１２から１８のいずれか一項に記載の方法。
20. 前記第２の処理コアは、アウトオブオーダ処理コアを含み、前記第１の処理コアは、インオーダ処理コアを含む、請求項１２から１８のいずれか一項に記載の方法。
21. コンピュータに請求項１２から２０のいずれか一項に記載の方法を実行させるためのプログラム。
22. 集積回路を備える異種マルチコア処理システムであって、前記集積回路は、
    プログラムコードを実行する第１のタイプの第１の処理コアと、
    前記プログラムコードを実行する、前記第１のタイプとは異なる第２のタイプの第２の処理コアと、
    前記第１の処理コアで第１の数のサイクルの間、前記プログラムコードを実行させ、前記第２の処理コアの立ち上げを信号で指示して、第２の数のサイクルの間、前記プログラムコードを実行する前記第１の処理コアの第１のパフォーマンスメトリックを収集するコード分配モジュールと、
    を備え、
    前記第１のパフォーマンスメトリックが、前に決定されたコアパフォーマンスメトリックより良好な場合には、前記コード分配モジュールは、前記第２の処理コアの電力を落とすよう信号で指示して、前記第１の処理コアで前記プログラムコードの実行を続け、
    前記第１のパフォーマンスメトリックが、前記前に決定されたコアパフォーマンスメトリックより良好ではない場合には、前記コード分配モジュールは、前記プログラムコードの実行を、前記第１の処理コアから前記第２の処理コアにスイッチして、第２の数のサイクルの間、前記プログラムコードを実行している前記第２の処理コアの第２のパフォーマンスメトリックを収集し、
    前記第２の処理コアの立ち上げを信号で指示することは、前記第１の数のサイクルと前記第２の数のサイクルの合計が終わる前に、第３の数のサイクルを立ち上げるよう信号で指示することを含む、異種マルチコア処理システム。
23. 前記第１のパフォーマンスメトリックが、前記前に決定されたコアパフォーマンスメトリックより良好な場合には、前記コード分配モジュールはさらに、前記前に決定されたコアパフォーマンスメトリックを、前記前に決定されたコアパフォーマンスメトリックをインフレーション係数で乗算した値に設定する、請求項２２に記載の異種マルチコア処理システム。
24. 前記コード分配モジュールは、さらに、前記第１の処理コアから前記第２の処理コアに、前記プログラムコードの実行を強制的にスイッチさせ、前記第２の数のサイクルの間、前記プログラムコードを実行する前記第２の処理コアの第２のパフォーマンスメトリックを、前記第１のパフォーマンスメトリックと前記前に決定されたコアパフォーマンスメトリックとをＫ回比較する毎に少なくとも１度、収集し、
    前記Ｋは自然数である、請求項２２または２３に記載の異種マルチコア処理システム。
25. 集積回路を備える異種マルチコア処理システムであって、前記集積回路は、
    プログラムコードを実行する第１のタイプの第１の処理コアと、
    前記プログラムコードを実行する、前記第１のタイプとは異なる第２のタイプの第２の処理コアと、
    前記第１の処理コアで第１の数のサイクルの間、前記プログラムコードを実行させ、前記第２の処理コアの立ち上げを信号で指示して、第２の数のサイクルの間、前記プログラムコードを実行する前記第１の処理コアの第１のパフォーマンスメトリックを収集するコード分配モジュールと、
    を備え、
    前記第１のパフォーマンスメトリックが、前に決定されたコアパフォーマンスメトリックより良好な場合には、前記コード分配モジュールは、前記第２の処理コアの電力を落とすよう信号で指示して、前記第１の処理コアで前記プログラムコードの実行を続け、
    前記第１のパフォーマンスメトリックが、前記前に決定されたコアパフォーマンスメトリックより良好ではない場合には、前記コード分配モジュールは、前記プログラムコードの実行を、前記第１の処理コアから前記第２の処理コアにスイッチして、第２の数のサイクルの間、前記プログラムコードを実行している前記第２の処理コアの第２のパフォーマンスメトリックを収集し、
    前記第１のパフォーマンスメトリックが、前記前に決定されたコアパフォーマンスメトリックより良好な場合には、前記コード分配モジュールはさらに、前記前に決定されたコアパフォーマンスメトリックを、前記前に決定されたコアパフォーマンスメトリックをインフレーション係数で乗算した値に設定する、異種マルチコア処理システム。
26. 集積回路を備える異種マルチコア処理システムであって、前記集積回路は、
    プログラムコードを実行する第１のタイプの第１の処理コアと、
    前記プログラムコードを実行する、前記第１のタイプとは異なる第２のタイプの第２の処理コアと、
    前記第１の処理コアで第１の数のサイクルの間、前記プログラムコードを実行させ、前記第２の処理コアの立ち上げを信号で指示して、第２の数のサイクルの間、前記プログラムコードを実行する前記第１の処理コアの第１のパフォーマンスメトリックを収集するコード分配モジュールと、
    を備え、
    前記第１のパフォーマンスメトリックが、前に決定されたコアパフォーマンスメトリックより良好な場合には、前記コード分配モジュールは、前記第２の処理コアの電力を落とすよう信号で指示して、前記第１の処理コアで前記プログラムコードの実行を続け、
    前記第１のパフォーマンスメトリックが、前記前に決定されたコアパフォーマンスメトリックより良好ではない場合には、前記コード分配モジュールは、前記プログラムコードの実行を、前記第１の処理コアから前記第２の処理コアにスイッチして、第２の数のサイクルの間、前記プログラムコードを実行している前記第２の処理コアの第２のパフォーマンスメトリックを収集し、
    前記コード分配モジュールは、さらに、前記第１の処理コアから前記第２の処理コアに、前記プログラムコードの実行を強制的にスイッチさせ、前記第２の数のサイクルの間、前記プログラムコードを実行する前記第２の処理コアの第２のパフォーマンスメトリックを、前記第１のパフォーマンスメトリックと前記前に決定されたコアパフォーマンスメトリックとをＫ回比較する毎に少なくとも１度、収集し、
    前記Ｋは自然数である、異種マルチコア処理システム。
27. 前記第２のパフォーマンスメトリックが前記第１のパフォーマンスメトリックより良好ではない場合、前記コード分配モジュールは、前記プログラムコードの実行を、前記第２の処理コアから前記第１の処理コアにスイッチして戻し、前記第２の処理コアの電力を落とすよう信号で指示する、請求項２２から２６のいずれか一項に記載の異種マルチコア処理システム。
28. 前記第２のパフォーマンスメトリックが前記第１のパフォーマンスメトリックより良好な場合、前記コード分配モジュールは、前記第１の処理コアの電力を落とすよう信号で指示し、前記前に決定されたコアパフォーマンスメトリックを、前記第１のパフォーマンスメトリックと前記第２のパフォーマンスメトリックとの平均に設定する、請求項２７に記載の異種マルチコア処理システム。
29. 前記第１の処理コアは、アウトオブオーダ処理コアを含み、前記第２の処理コアは、インオーダ処理コアを含む、請求項２２から２８のいずれか一項に記載の異種マルチコア処理システム。
30. 前記第２の処理コアは、アウトオブオーダ処理コアを含み、前記第１の処理コアは、インオーダ処理コアを含む、請求項２２から２８のいずれか一項に記載の異種マルチコア処理システム。

Images