"異種マルチコア処理システムで動的にコアをスイッチする方法であって、前記異種マルチコア処理システムの第1のタイプの第1の処理コアでプログラムコードを実行する段階と、前記プログラムコードを実行する前記第1の処理コアのパフォーマンスを監視して、統計データを収集する段階と、前記第1の処理コアについての監視された前記パフォーマンスおよび収集された前記統計データに少なくとも一部基づいて、前記異種マルチコア処理システムの、前記第1のタイプと異なる第2のタイプの第2の処理コアで前記プログラムコードを実行する際のパフォーマンスを予測する段階と、予測された、前記第2の処理コアで前記プログラムコードを実行する際のパフォーマンスが、前記プログラムコードを実行する前記第1の処理コアのパフォーマンスよりも良好である場合には、前記プログラムコードの実行を、前記第1の処理コアから前記第2の処理コアにスイッチする段階とを備える方法。予測された、前記第2の処理コアで前記プログラムコードを実行する際のパフォーマンスが、前記プログラムコードを実行する前記第1の処理コアのパフォーマンスよりも良好である場合には、前記第2の処理コアを、低電力状態から立ち上げる段階をさらに備える、請求項1に記載の方法。予測された、前記第2の処理コアで前記プログラムコードを実行する際のパフォーマンスが、前記プログラムコードを実行する前記第1の処理コアのパフォーマンスよりも良好である場合には、前記第1の処理コアを低電力状態に落とす段階をさらに備える、請求項1または2に記載の方法。前記第1の処理コアは、アウトオブオーダ処理コアを含み、前記第2の処理コアは、インオーダ処理コアを含む、請求項1から3のいずれか一項に記載の方法。前記第2の処理コアは、アウトオブオーダ処理コアを含み、前記第1の処理コアは、インオーダ処理コアを含む、請求項1から3のいずれか一項に記載の方法。前記第2の処理コアのパフォーマンスを予測する段階は、複数のコードセグメントを、前記第1の処理コアおよび前記第2の処理コアの両方で実行する段階と、前記コードを実行している間に、前記第1の処理コアおよび前記第2の処理コアのそれぞれのパフォーマンス情報および統計データを収集する段階と、最良適合関数bestfitfunctionF前記第1の処理コアのパフォーマンス情報および統計データと、前記第2の処理コアのパフォーマンスとの間の差が最小になるように前記Fを決定する段階とを有する、請求項1から5のいずれか一項に記載の方法。コンピュータに請求項1から6のいずれか一項に記載の方法を実行させるためのプログラム。集積回路を備える異種マルチコア処理システムであって、前記集積回路は、プログラムコードを実行する第1のタイプの第1の処理コアと、前記プログラムコードを実行する、前記第1のタイプとは異なる第2のタイプの第2の処理コアと、コード分配モジュールとを備え、前記コード分配モジュールは、前記プログラムコードを実行する前記第1の処理コアのパフォーマンスを監視して、統計データを収集して、前記第1の処理コアについての監視された前記パフォーマンスおよび収集された前記統計データに少なくとも一部基づいて、前記第2の処理コアで前記プログラムコードを実行する際のパフォーマンスを予測して、予測された、前記第2の処理コアで前記プログラムコードを実行する際のパフォーマンスが、前記プログラムコードを実行する前記第1の処理コアのパフォーマンスよりも良好である場合には、前記プログラムコードの実行を、前記第1の処理コアから前記第2の処理コアにスイッチする、異種マルチコア処理システム。前記コード分配モジュールは、予測された、前記第2の処理コアで前記プログラムコードを実行する際のパフォーマンスが、前記プログラムコードを実行する前記第1の処理コアのパフォーマンスよりも良好である場合には、前記第2の処理コアを、低電力状態から立ち上げる、請求項8に記載の異種マルチコア処理システム。前記コード分配モジュールは、予測された、前記第2の処理コアで前記プログラムコードを実行する際のパフォーマンスが、前記プログラムコードを実行する前記第1の処理コアのパフォーマンスよりも良好である場合には、前記第1の処理コアを低電力状態に落とす、請求項8または9に記載の異種マルチコア処理システム。前記第1の処理コアは、アウトオブオーダ処理コアを含み、前記第2の処理コアは、インオーダ処理コアを含む、請求項8から10のいずれか一項に記載の異種マルチコア処理システム。前記第2の処理コアは、アウトオブオーダ処理コアを含み、前記第1の処理コアは、インオーダ処理コアを含む、請求項8から10のいずれか一項に記載の異種マルチコア処理システム。異種マルチコア処理システムで動的にコアをスイッチする方法であって、前記異種マルチコア処理システムの第1のタイプの第1の処理コアでプログラムコードを、第1の数のサイクルの間、実行する段階と、前記異種マルチコア処理システムの、前記第1のタイプと異なる第2のタイプの第2の処理コアの立ち上げを信号で指示する段階と、第2の数のサイクルの間、前記プログラムコードを実行する前記第1の処理コアの第1のパフォーマンスメトリックを収集する段階と、前記第1のパフォーマンスメトリックが、前に決定されたコアパフォーマンスメトリックより良好な場合には、前記第2の処理コアの電力を落とすよう信号で指示して、前記第1の処理コアで前記プログラムコードの実行を続け、前記第1のパフォーマンスメトリックが、前記前に決定されたコアパフォーマンスメトリックより良好ではない場合には、前記プログラムコードの実行を、前記第1の処理コアから前記第2の処理コアにスイッチして、第2の数のサイクルの間、前記プログラムコードを実行している前記第2の処理コアの第2のパフォーマンスメトリックを収集する段階とを備える方法。前記第2のパフォーマンスメトリックが前記第1のパフォーマンスメトリックより良好ではない場合、前記プログラムコードの実行を、前記第2の処理コアから前記第1の処理コアにスイッチして戻し、前記第2の処理コアの電力を落とすよう信号で指示する段階をさらに備える、請求項13に記載の方法。前記第2のパフォーマンスメトリックが前記第1のパフォーマンスメトリックより良好な場合、前記第1の処理コアの電力を落とすよう信号で指示し、前記前に決定されたコアパフォーマンスメトリックを、前記第1のパフォーマンスメトリックと前記第2のパフォーマンスメトリックとの平均に設定する段階をさらに備える、請求項14に記載の方法。前記第2の処理コアの立ち上げを信号で指示する段階は、前記第1の数のサイクルと前記第2の数のサイクルの合計が終わる前に、第3の数のサイクルを立ち上げるよう信号で指示する段階を有する、請求項13から15のいずれか一項に記載の方法。前記第1のパフォーマンスメトリックが、前記前に決定されたコアパフォーマンスメトリックより良好な場合には、前記前に決定されたコアパフォーマンスメトリックを、前記前に決定されたコアパフォーマンスメトリックを、インフレーション係数で乗算した値に設定する段階をさらに備える、請求項13から16のいずれか一項に記載の方法。前記第1の処理コアから前記第2の処理コアに、前記プログラムコードの実行を強制的にスイッチさせ、第2の数のサイクルの間、前記プログラムコードを実行する前記第2の処理コアの第2のパフォーマンスメトリックを、前記第1のパフォーマンスメトリックと前記前に決定されたコアパフォーマンスメトリックとをK回比較する毎に少なくとも1度、収集する段階をさらに備え、前記Kは自然数である、請求項13から17のいずれか一項に記載の方法。前記第1の処理コアは、アウトオブオーダ処理コアを含み、前記第2の処理コアは、インオーダ処理コアを含む、請求項13から18のいずれか一項に記載の方法。前記第2の処理コアは、アウトオブオーダ処理コアを含み、前記第1の処理コアは、インオーダ処理コアを含む、請求項13から18のいずれか一項に記載の方法。コンピュータに請求項13から20のいずれか一項に記載の方法を実行させるためのプログラム。集積回路を備える異種マルチコア処理システムであって、前記集積回路は、プログラムコードを実行する第1のタイプの第1の処理コアと、前記プログラムコードを実行する、前記第1のタイプとは異なる第2のタイプの第2の処理コアと、前記第1の処理コアで第1の数のサイクルの間、前記プログラムコードを実行させ、前記第2の処理コアの立ち上げを信号で指示して、第2の数のサイクルの間、前記プログラムコードを実行する前記第1の処理コアの第1のパフォーマンスメトリックを収集するコード分配モジュールと、を備え、前記第1のパフォーマンスメトリックが、前に決定されたコアパフォーマンスメトリックより良好な場合には、前記コード分配モジュールは、前記第2の処理コアの電力を落とすよう信号で指示して、前記第1の処理コアで前記プログラムコードの実行を続け、前記第1のパフォーマンスメトリックが、前記前に決定されたコアパフォーマンスメトリックより良好ではない場合には、前記コード分配モジュールは、前記プログラムコードの実行を、前記第1の処理コアから前記第2の処理コアにスイッチして、第2の数のサイクルの間、前記プログラムコードを実行している前記第2の処理コアの第2のパフォーマンスメトリックを収集する、異種マルチコア処理システム。前記第2のパフォーマンスメトリックが前記第1のパフォーマンスメトリックより良好ではない場合、前記コード分配モジュールは、前記プログラムコードの実行を、前記第2の処理コアから前記第1の処理コアにスイッチして戻し、前記第2の処理コアの電力を落とすよう信号で指示する、請求項22に記載の異種マルチコア処理システム。前記第2のパフォーマンスメトリックが前記第1のパフォーマンスメトリックより良好な場合、前記コード分配モジュールは、前記第1の処理コアの電力を落とすよう信号で指示し、前記前に決定されたコアパフォーマンスメトリックを、前記第1のパフォーマンスメトリックと前記第2のパフォーマンスメトリックとの平均に設定する、請求項23に記載の異種マルチコア処理システム。前記第2の処理コアの立ち上げを信号で指示することは、前記第1の数のサイクルと前記第2の数のサイクルの合計が終わる前に、第3の数のサイクルを立ち上げるよう信号で指示することを含む、請求項22から24のいずれか一項に記載の異種マルチコア処理システム。前記第1のパフォーマンスメトリックが、前記前に決定されたコアパフォーマンスメトリックより良好な場合には、前記コード分配モジュールはさらに、前記前に決定されたコアパフォーマンスメトリックを、前記前に決定されたコアパフォーマンスメトリックを、インフレーション係数で乗算した値に設定する請求項22から25のいずれか一項に記載の異種マルチコア処理システム。前記コード分配モジュールは、さらに、前記第1の処理コアから前記第2の処理コアに、前記プログラムコードの実行を強制的にスイッチさせ、第2の数のサイクルの間、前記プログラムコードを実行する前記第2の処理コアの第2のパフォーマンスメトリックを、前記第1のパフォーマンスメトリックと前記前に決定されたコアパフォーマンスメトリックとをK回比較する毎に少なくとも1度、収集し、前記Kは自然数である、請求項22から26のいずれか一項に記載の異種マルチコア処理システム。前記第1の処理コアは、アウトオブオーダ処理コアを含み、前記第2の処理コアは、インオーダ処理コアを含む、請求項22から27のいずれか一項に記載の異種マルチコア処理システム。前記第2の処理コアは、アウトオブオーダ処理コアを含み、前記第1の処理コアは、インオーダ処理コアを含む、請求項22から27のいずれか一項に記載の異種マルチコア処理システム。異種コンピューティング戦略は、それぞれのコアが特定のコードを実行するのには効率がよいが、他のコードを実行するのには効率が悪いような複数のコアを統合するものである。ランタイムソフトウェアSWおよびハードウェアHWは、協力して、入力プログラムを、別々のコアに適したコードセグメントに分割して、これらそれぞれを最も適したコアの上で実行して、同時に、他のコアを低電力状態にしておき、低電力およびエネルギー消費において高いパフォーマンスを達成する。このようなシステムの一例は、少なくとも1つの広帯域インオーダコアと、少なくとも1つの狭帯域アウトオブオーダコアとからなり、本発明の実施形態においては、この異質システムが、アウトオブオーダコアのパフォーマンスを向上させ、且つ、エネルギーおよび電力の一部しか消費しない。このタイプのコンピューティングシステムの主要な課題は、プログラムの振る舞いの変化を迅速に特定して、適切なコアにランタイムにおいて効率的にスイッチする、ということである。本発明の実施形態では、ランタイムソフトウェアおよび/またはハードウェアを利用して、同じプログラムの別々のコードセグメントを最も適したコアの実行を自動的に切り換えて、シングルスレッドプログラムのパフォーマンス速度を顕著に速くする。以下の記載では、具体的なプロセッサコアの種類、具体的なプロセッサ構成、具体的なホットコード領域特定アルゴリズム、変換/最適化コードを格納する具体的な構造、ハードウェア/ソフトウェアの間のタスクの具体的な分割法、具体的なプロセッサユニット/論理等についての例など、複数の具体的な詳細を述べ、本発明の完全な理解を提供している。しかし当業者には、本発明を実施するためにこれらの具体的な詳細が必ずしも利用されなくてもよいことが明らかである。また、公知のコンポーネントまたは方法たとえば特定およびその他のプロセッサアーキテクチャ、記述されたアルゴリズム用の具体的な論理回路/コード、具体的なコード実装、具体的なバイナリ変換の詳細、およびその他のマイクロプロセッサの具体的なオペレーションの詳細は、詳述を避けて、本発明の不当にあいまいにしないようにしている箇所もある。一実施形態では、ここの記載する方法および装置は、最大のパフォーマンスおよび節電効果を実現するために、ソフトウェア管理されているコアをもつネイティブコアを実装することである。特に、コア間の協力は、まず一義的に、アウトオブオーダコアおよびインオーダの共同設計コアを参照して説明する。しかし、ここに記載する装置および方法は、これらに限定はされず、異種コア間でコードを分配するいずれの様式に実装することもできる。たとえば、ここで記載するコード分配方法および装置は、固有の命令セットアーキテクチャISAを実装する2つのアウトオブオーダコアとともに利用することもできる。さらに、これらコアの間の協力が、しばしば、ハードウェアメカニズムおよびコード/ソフトウェアの間で分割されるものとして記載される場合がある。しかし、後述する方法および装置を実装するために利用可能なハードウェア、ソフトウェア、および/またはファームウェアは適宜組み合わせまたは排他的利用することが可能である。図1は、複数のコアを含む1つのプロセッサの一実施形態を示している。プロセッサ100は、マイクロプロセッサ、エンベデッドプロセッサ、デジタル信号プロセッサDSP、ネットワークプロセッサ、またはコードを実行するその他のデバイス等の任意のプロセッサであってよい。一実施形態では、プロセッサ100は、それぞれ異なる種類のコア101および102という少なくとも2つのコアを含む。しかし、プロセッサ100は、任意の数の処理エレメントを含んでよい。一実施形態では、処理エレメントは、スレッドユニット、スレッドスロット、処理ユニット、コンテキスト、論理プロセッサ、ハードウェアスレッド、コア、および/または、プロセッサの状態たとえば実行状態またはアーキテクチャ状態を維持することができる任意の他のエレメントのことであってよい。言い換えると、一実施形態において処理エレメントとは、ソフトウェアスレッド、オペレーティングシステム、アプリケーション、その他のコードといったコードに独立して関連付けることができる任意のハードウェアのことであってよい。物理的なプロセッサは通常、コアまたはハードウェアスレッドといった任意の数の他の処理エレメントを潜在的に含むことができる集積回路のことであってよい。コアは、それぞれ独立して維持されるアーキテクチャ状態が少なくともいくつかの専用実行リソースと関連付けられている独立アーキテクチャ状態を維持することができる集積回路上に位置する論理のことを指す場合が多い。コアに対して、ハードウェアスレッドとは、通常、独立して維持されるアーキテクチャ状態が実行リソースに対するアクセスを共有する独立アーキテクチャ状態を維持することができる集積回路上に位置する任意の論理のことである。上記からわかるように、特定のリソースが共有されている場合、他のリソースはアーキテクチャ状態専用であり、ハードウェアスレッドとコアとの境目は曖昧である。しかししばしば、コアとハードウェアスレッドとは、オペレーティングシステムから個別の論理プロセッサとみられており、オペレーティングシステムは、各論理プロセッサ上での動作を個々にスケジュールすることができる。物理的プロセッサ100図1に示すは、2つのコアコア101および102を含む。ここでコア101およびコア102は、異質コアと考えることができるつまり、それぞれ異なる構成、機能ユニットおよび/または論理をもつコアのこと。一実施形態では、コア101は、アウトオブオーダプロセッサコアを含み、コア102が、インオーダプロセッサコアを含む。しかしコア101および102は、任意のタイプのコアから個々に選択されてよい。しかし説明を続けるために、図1に示す機能ユニットを以下で詳述する。記載したようにコア101は、2つのハードウェアスレッド101aおよび101bを含み、これらは、ハードウェアスレッドスロット101aおよび101bとも称される場合がある。これに対して、コア102は、1つのハードウェアスレッド102aを含んでいる。したがって、ソフトウェア実体たとえばオペレーティングシステムは、一実施形態では、プロセッサ100を、3つのソフトウェアスレッドを同時に実行することができる3つの別個のプロセッサつまり3つの論理プロセッサまたは処理エレメントとみなす。この代わりに、ソフトウェア実体は、プロセッサ100を、2つの別個のプロセッサスレッドスロット101aおよび101bをもつものとしてみなすこともでき、記載するコードの分配メカニズムが、コア102上でのコードに実行を管理する。第1のスレッドは、アーキテクチャ状態レジスタ101aに関連付けられており、第2のスレッドは、アーキテクチャ状態レジスタ101bに関連付けられており、第3のスレッドは、アーキテクチャ状態レジスタ102aに関連付けられていてよい。図示するように、アーキテクチャ状態レジスタ101aは、アーキテクチャ状態レジスタ101bに複製されており、個々のアーキテクチャ状態/コンテキストが、論理プロセッサ101aおよび論理プロセッサ101bのために格納可能である。アーキテクチャ状態レジスタ102aは、レジスタ101a、101bと同じであってもよい。または、レジスタ102aが、コア102のアーキテクチャに固有であってもよい。コア101では、他のより小さいリソースたとえば、リネームアロケータ論理130の命令ポインタおよびリネーミング論理も、スレッド101aおよび101b用に複製されてよい。一部のリソースたとえば、リオーダ/リタイヤユニット135のリオーダバッファ、命令-変換バッファITLB120、ロード/格納バッファ、およびキューが、分割によって共有されてもよい。他のリソースたとえば、汎用内部レジスタ、ページ-テーブルベースレジスタ、低レベルデータ-キャッシュおよびデータ-TLB150、実行ユニット140、およびアウトオブオーダユニット135の幾つかの部分が、潜在的に完全共有されてもよい。しばしばプロセッサ100は、完全共有されていたり、分割により共有されたり、処理エレメント専用であったりしてよい他のリソースを含む場合がある。図1では、プロセッサの例示的な論理ユニット/リソースをもつ、純粋に例であるプロセッサの実施形態が示されている。プロセッサは、これら機能ユニットのいずれかを含んでも、含まなくてもよく、同時に、図示されていない任意の他の公知の機能ユニット、論理、またはファームウェアを含んでもよい。図では、コア101は、単純化されたアウトオブオーダOOOプロセッサコアとして示されている。OOOコアは、実行/とられるべき分岐を予測するための分岐対象バッファBTB120、および、命令用にアドレス変換エントリを格納するための命令-変換バッファI-TLB120を含む。コア101はさらに、フェッチユニット120に連結されて、フェッチされたエレメントをデコードするためのデコードモジュール125を含む。一実施形態では、フェッチ論理は、それぞれ、スレッドスロット101a、101bに関連付けられている個々のシーケンサを含む。通常、コア101は、プロセッサ100上で実行可能な命令を定義/特定する第1の命令セットアーキテクチャISAに関連付けられている。ここで、しばしば、第1のISAの一部である機械コード命令が、実行すべき命令またはオペレーションを参照/特定する、命令の一部オペコードと称されるを含む。デコード論理125は、これら命令を自身のオペコードから認識して、デコードされた命令を、第1のISAが定義する処理を受けさせるためにパイプラインに送る回路を含んでいる。一例では、アロケータリネーマブロック130が、結果を処理する命令を格納するリソースレジスタファイルをリザーブするアロケータを含む。しかしスレッド101aおよび101bは、潜在的に、アウトオブオーダ実行をすることができ、アロケータおよびリネーマブロック130も、他のリソースたとえば、命令ステータスを追跡するためのリオーダバッファを含んでよい。ユニット130は、さらに、プログラム/命令参照レジスタをプロセッサ100内部の他のレジスタにリネームするレジスタリネーマを含んでよい。リオーダ/リタイヤユニット135は、コンポーネントたとえば上述したリオーダバッファ、ロードバッファ、および格納バッファを含み、アウトオブオーダ実行をサポートして、後では、アウトオブオーダ実行された命令のインオーダリタイヤをサポートする。スケジューラおよび実行ユニットブロック140は、一実施形態では、実行ユニットの命令/オペレーションをスケジュールするためのスケジューラユニットを含む。たとえば、浮動小数点命令が、利用可能な浮動小数点実行ユニットを有する実行ユニットの一部に対してスケジュールされる。実行ユニットに関連づけられているレジスタファイルも、結果を処理する情報命令を格納するために含まれている。例である実行ユニットは、浮動小数点実行ユニット、整数実行ユニット、ジャンプ実行ユニット、ロード実行ユニット、格納実行ユニット、およびその他の公知の実行ユニットを含む。低レベルデータキャッシュおよびデータアドレス変換ルックアップ/サイドバッファD-TLB150が、実行ユニット140に連結されている。データキャッシュは、エレメントに最近利用された/操作されたものを格納するたとえば、メモリコヒーレンシー状態に潜在的に維持されているデータオペランド。D-TLBは、物理的アドレス変換に対して最近の仮想/リニアを格納する。具体的な例としては、プロセッサは、物理的メモリを複数の仮想ページに分割するためにページテーブル構造を含んでよい。上述したように、一実施形態では、コア102が、インオーダ、共同設計コアを含む。この結果、図1は、インオーダコアの簡略化されたパイプラインを示している。このパイプラインは、フェッチユニット121、デコードユニット126、実行ユニット1または複数141、および低レベルデータキャッシュ151を含む。これらユニットは、コア101の対応するユニットに同様に動作してよい。しかしインオーダコアでは、命令/オペレーションが、プログラム順に実行されるコア101におけるような潜在的なアウトオブオーダ実行ではなく。一例としては、アウトオブオーダコア101が、ネイティブコアと称され、インオーダコア102は、共同設計コアと称される。この代わりに、インオーダコア102が、ネイティブコアであり、アウトオブオーダコア101が共同設計コアであってもよい。ここで、コア101および102は、最近フェッチされたエレメントをキャッシュするための、より高レベルまたはさらに外側のfurtheroutキャッシュ110に対するアクセスを共有する。ここで、より高レベルまたはさらに外側とは、キャッシュレベルが増加する、または、実行ユニットからさらに離れることを意味している。一実施形態では、より高レベルのキャッシュ110が、最終レベルデータキャッシュである第2または第3レベルデータキャッシュのような、プロセッサ100のメモリ階層で最終のキャッシュ。しかし、より高レベルキャッシュ110は、命令キャッシュに関連付けられていれば、または、命令キャッシュを含んでいればいいのであって、これに限定はされない。追跡キャッシュ命令キャッシュの一種が、この代わりに、デコーダ125の後に連結されていて、最近デコードされたトレースを格納してもよい。図示されている構成では、プロセッサ100はさらに、リンクインタフェースモジュール105を含み、プロセッサ100外のデバイスたとえば、システムメモリ175、チップセット、ノースブリッジ、その他の集積回路たとえばシステムオンチップsystemonachipSOC等の1つの集積回路実装を含むと通信する。メモリ175は、プロセッサ100専用であっても、システム内の他のデバイスと共有されてもよい。メモリ175の種類のよくある例としては、ダイナミックランダムアクセスメモリDRAM、スタティックRAMSRAM、不揮発性メモリNVメモリ、その他の公知の記憶デバイスが含まれる。一実施形態では、コードが、コア101および102の間で、最大のパフォーマンスおよび節電効果に基づいて分配される。たとえば、コード領域が、2つのコア101、102のいずれかにより良く実行されるように特定される。この結果、これらコード領域のいずれかに遭遇したり、これらコード領域のいずれかを検知したりするとき、このコードセクションが適切な分配されることになる。これら領域の特定は、静的にコードの実行前、たとえばプログラムプロフィール分析によって行われてもよいし、ハードウェア、ソフトウェア、またはこれらの組み合わせによって動的にコードの実行中に行われてもよい。動的な方法の一例では、1つのプロセッサコアたとえばコア101が、パフォーマンス、節電、ネイティブISA,任意の他の公知の処理の考慮、またはこれらの組み合わせに基づいてコードを実行するデフォルトコアとして選択されてよい。そして、コア101での実行状態が良くない、または、コア102での実行状態のほうが良いと見込まれるデフォルトコアの領域を特定する。後でこれら特定されたコードのセクションに遭遇すると、実行されるべくコア102に分配される。これら領域のコア102における実行には、ウォームアップコア101に対する投機的、ランアヘッド実行、コア102のこれら領域に対するシリアル実行と、これら領域の結果に依存するコア101の他の領域に対する実行との組み合わせ、または、これらの領域の同時実行と、コア102の他のコードの実行との組み合わせが含まれてよい。静的な方法の一例では、コンパイラまたはユーザが、あるコアその他のコアでより良く実行されるコードのセクションを特定してよいたとえば、命令またはデマケーションにより。ここで、コア101は、これらの命令に遭遇するまではコードを実行する。コア102からの監視に呼応する、または、コア102単独の判断トリガによって、特定されたコードのセクションを次に、遭遇した命令に基づいてコア102で実行する。1つのコアまたは別のコアでの実行するほうが良いコードのセクションの特定を、動的または静的に行うかによって、一部の実施形態では、ネイティブコードを別のコアで実行するよう変換したり、および/または、最適化したりする。たとえば、コア101が、第1のISAタイプを認識するデコード論理125を含み、コア102が、第2のISAタイプを認識するデコード論理126を含むと想定する。この場合、第1のISAタイプのコード領域が、コア102で実行され、次に、コード領域を第2のISAタイプに変換して、コア102で実行させる。ISAタイプの間の変換は純粋な例である。この代わりに、コア101で実行されるアウトオブオーダ最適化コードを、インオーダコア102の実行用に再度最適化する。このシナリオでは、コア102は、同じもの、またはコア101の同じISAのサブセットを含んでよい。または、最適化を、コードに行って、単純な、広帯域のイノーダコアに確実により効率的に実行されるようにしてもよい。コードを効率的に分配するための、コア101とコア102との間の協力は、ハードウェア、ファームウェア、ソフトウェア、またはこれらの組み合わせで実行されてもよい。上述した、コード領域を特定するために動的な方法に関する例をさらに照査して、協力メカニズムの実施形態を説明する。この例では、ネイティブフォーマットのプログラムコードが、アウトオブオーダコア101での実行用に最適化される。コード領域またはプログラムコードの実行中に、コア101および/またはコア102に関するモニタハードウェアが、コード領域のコア101の実行に関するパフォーマンスを決定するために利用されてよい。この代わりに、ソフトウェア、OSコード、マイクロコード、またはその他のコード等のモニタハードウェアが、コア102で実行され、これによりコード領域の実行の際のコア101のパフォーマンスを判断/監視してもよい。そのコード領域がコア102で実行されるほうがよいと判断されると、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせを利用して、コア102で実行するコード領域を変換および/または最適化してよい。この結果、コア101がコード領域に再度遭遇すると命令ポインタがコード領域を参照すると、コード領域を識別する識別子命令がフェッチされデコードされ、または、コード領域を特定する別の方法が検知され、次に、コード領域の変換/最適化されたバージョンがコア102で実行される。一実施形態では、コード領域がコア102で実行されている間、コア101は、他のコード領域を同時に実行して、プログラム実行パフォーマンス全体を高める。同時または並列実行は、コア101、102での別個のソフトウェアスレッド実行を含んでよい。これに対して、スレッドは、コア101、102でパイプライン実行されてよい。このシナリオの一例として、2つのソフトウェアスレッドの各々が、多くのコード段階ホット、コールドなどを含むと想定する。ここで、第1のステッドからのコールドコードは、コア101で実行されてよく、ホットな領域に遭遇すると、変換されたホットな領域をコア102で実行する。コア102でコードの変換されたホットな領域が実行されている間、第2のスレッドからのコールドコードがコア101で実行されてよい。コア102では、第1の変換されたホットコードの実行が完了すると、第2のソフトウェアスレッドからの別のホットな領域の実行が開始されてよい。この例からわかるように、コードの段階は、パイプラインタイプの実行を生じる各コアにインタリーブされてよい。別の実施形態では、コードが、2つのコアコア101のコード領域、コア102で特定されたコード領域、その後に、コア101の別のコード領域といったようにに対して連続実行されてよい。加えて、コード領域がコア102での実行のために最初に特定された場合であっても、その実行のパフォーマンスを監視することができる。次に、最大のパフォーマンスおよび節電効果を達成するためにどのコアがコード領域の実行に最も適しているかを判断するために、両方のコアのパフォーマンスが考慮されてもよい。たとえば、あるコード領域が、コア102上で変換されたコードとして実行されるものとして特定されたが、コア102でのパフォーマンスがコア101でのパフォーマンスを下回るような場合または、コア102でのパフォーマンス利得が、コア201で実行される際の節電量を上回らないような場合、後で遭遇したときに、コア101に対してコードを再分配することができる。図1は、それぞれ別のモジュール、ユニット、および/または論理を表す、例示的なプロセッサの抽象的な論理図である。しかし、ここで記載する方法および装置を利用するプロセッサは、例示したユニットを含まなくてもよい点を理解されたい。プロセッサは、示されているユニットの一部または全てを含まなくてもよい。さらに、記載の大半は、アウトオブオーダプロセッサコアとインオーダプロセッサコアとを参照して行われる。しかし、上述したように、2つのプロセッサコアは、異種のコアバージョンであればいずれであってもよいたとえば、ネイティブコアとソフトウェア管理されているコア等。加えて、図1は2つのコアのみを示しているが、プロセッサは任意の数のコアを含んでよいたとえば、同じタイプの複数のコア、および、互いにタイプの異なる2を超える数のコア。図1は、外部メモリコントローラコントローラハブ170に対するインタフェースを有するポイントツーポイント法で連結されたプロセッサの一実施形態を示す。しかし、既に数多くのプロセッサ複数のコア、および共有キャッシュおよびその他のインタフェースをインターコネクトするリング構成を有するオンプロセッサメモリインタフェースモジュールオンチップモジュールが存在している。図示はされていないが、一実施形態では、プロセッサ100が、コア、キャッシュ、およびメモリコントローラコンポーネントを連結するリングインターコネクトを含んでいる。ここで、キャッシュエージェントを利用して、物理的に分配しているキャッシュのスライスを管理することができる。一例としては、各キャッシュコンポーネントが、配列コアcollocatedcoreキャッシュエージェントが、キャッシュの分配されたスライスを管理する目的のために関連付けられているコアのためのキャッシュのスライスを管理する。キャッシュエージェントがキャッシュスライスとのリングインターコネクトおよびインタフェースのトラフィックを取り扱うのと同様に、コアエージェント/コンポーネントが、コアとのトラフィックおよびインタフェースを取り扱う。加えて、リングインターコネクトは、メモリコントローラインタフェース論理MCILおよび/または他のコントローラを連結して、他のモジュールたとえばメモリおよび/またはグラフィックプロセッサとインタフェースさせてよい。図2を参照すると、2つのコア間でコードを分配させるコード分配モジュールの一実施形態が示されている。一実施形態では、コア201、202が、異種コアである。たとえばコア201は、元のプログラム順序ではない順序でコードを実行するよう適合されているアウトオブオーダOOOコアであり、コア202は、プログラム順序でコードを実行するよう適合されているインオーダまたはシリアルコアである。他のコアのタイプの非包括的な例のリストには、ネイティブコア、非ネイティブコア、ソフトウェア管理されているコア、ネイティブISAコア、変換されたISAコア、共同設計コア、投機的実行コア、および非投機的コアが含まれる。一実施形態では、コード分配モジュール210が、コードをコア201および202の間で、最大のパフォーマンスおよび節電効果に基づいて分配させる。ここで利用するモジュールは、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせのことであってよい。加えて、モジュール、ユニット、または論理は、1つのコアまたはプロセッサに集中されていても、全体に分散されていてもよい。たとえば、コード分配モジュール210は、マイクロコードまたはソフトウェア等の、コア201、コア202、プロセッサ200、またはプロセッサ200を含むシステムに関連付けられているストレージに保持されている分配コードを含んでよい。ここで、分配コードは、実行されると、コードの分配を実行する。これに対して、コード分配プロセスは、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせで管理されてよい。一実施形態では、コード分配モジュール210は、プログラムコードの実行をあるコアから別のコアへと動的に切り替える。動的切り替えプログラムコードは、図4および図5を参照して後で詳述する。しかし、このセクションの説明としては、プログラムコードは、処理エレメントたとえばバイナリまたは機械コードで実行される任意のコードを含んでよい。コードのホットな部分は、考慮要件たとえば電力、パフォーマンス、熱、その他の公知のプロセッサメトリック、またはこれらの組み合わせに基づいて、他よりあるコアで実行するほうが適しているコードの部分のことであってよい。ここで、コア201が、プログラムコードのネイティブ実行のためのデフォルトのコアであると想定すると、プログラムコードのホットな部分の特定は、コア202での実行により適しているコードの部分を判断することを含む。コア201がOOOコアでありコア202がインオーダコアである実施形態では、コードのホットな部分が、シリアルコア202での実行により適したプログラムコードのホットスポットのことであってよく、この部分は、潜在的に高い反復セクションの実行のためにより有用なリソースを有している可能性がある。一例として、コードのホットな部分を、コードのその部分の反復パターンで特定し、または、その他の公知のメトリックで特定するたとえば命令カウントまたはサイクルカウント。反復の可能性が高くhighrecurrence、予測可能なレイテンシーパターンをもつコードのセクションが、しばしば、インオーダコアでより有効に実行されるよう最適化されるとよい場合が多い。本質的には、この例で、コールドコード反復の可能性が低いlowrecurrenceは、ネイティブのOOOコア101に分配され、ホットコード反復の可能性が高いは、ソフトウェア管理されているインオーダコア102に分配される。コードのホットな部分は、静的に、動的に、またはこれらの組み合わせで特定することができる。最初の場合、コンパイラまたはユーザは、プログラムコードのセクションがホットコードであると判断してよい。ここで、ホットコード識別子命令は、コードの一セクションをホットコア101でではなくてコア202で実行されるとして区別するdemarcateすることができる。コア201のデコード論理は、一実施形態では、プログラムコードからホットコード識別子命令をデコードするよう適合されており、これは、プログラムコードのホットな部分を特定する。これらの命令のフェッチまたはデコードは、コア202におけるコードのホットなセクションの変換および/または実行をトリガしてよい。この例では、コード分配モジュール210は、ホットコード検知命令を検知するデコード論理を含む。そしてモジュール210は、さらに、コア202におけるホットコードの変換/最適化および実行を行う他のハードウェアおよび/またはソフトウェアを含んでよい。この代わりに、ホットコードのセクションは、コア202での実行のために予め最適化/変換されてよい。別の例においては、コード分配モジュール210は、動的に実行中に、プログラムコードのホットスポット/領域を特定する。一実施形態では、コア201および/またはコア202に含まれているハードウェアは、コアたとえばコア201におけるプログラムコードのプロフィール実行を行うために利用される。プロフィールの特徴に基づいて実行にまつわる電力および/パフォーマンスメトリック、プログラムコードの1つの領域をホットコードとして特定することができる。ハードウェアのオペレーションに類似して、監視コードを1つのコアたとえばコア202の上で実行して、他のコアコア201で実行されているプログラムコードの監視/プロフィールを実行してよい。このような監視コードは、プロセッサ200内のコア内の格納構造に維持されたり、プロセッサ200を含むシステムで維持されたりするコードであってよい。たとえば、監視コードは、コア201、コア202、またはプロセッサ200の格納構造に維持されるマイクロコードまたはその他のコードであってよい。そして、監視コードは、従来の実行ユニットおよびプロセッサ200の他のファームウェアまたは論理によって実行されてよい。また別の例として、ホットコードの静的識別が、ヒントとして作成される。しかしプログラムコード実行の動的プロファイルは、コードの一領域のホットとしての静的な識別を無視することができ、このタイプの静的識別はしばしば、動的プロファイルがコード分配に適したコアを判断する際に考慮するコンパイラまたはユーザヒントとして参照される。さらに、動的プロファイルの性質として、コードの1つの領域をホットとして特定することによって、コードのそのセクションが常にホットとして特定されるわけではない。たとえば、プログラムコードがアウトオブオーダコア201で実行されていると想定する。コア202で実行されている監視コードは、プログラムコードの1つのセクションのコア201の実行のパフォーマンスレベルを監視する。実装に基づき、コア201のパフォーマンスが、コア202で実行されるよりも十分低いと判断されると、および/または、コア201におけるコードのセクションの反復パターンが、コアの遷移オーバヘッドを隠すと予測することができる程度に十分高いと判断されると、コードのセクションをホットとして特定する。変換および/または最適化の後に、コードのセクションの変換されたバージョンをコア202で実行する。コア201における実行の監視同様に、たとえばパフォーマンス監視コードの実行によって、コードの変換されたバージョンの実行もコア202で監視されてよい。パフォーマンスがコア201におけるよりコア202においてのほうが低い場合には、コードのセクションをホットと特定することを、動的に逆にすることもできるホットコードのセクションをコールドコードとして命名しなおしてよい。ひとたびコードのあるセクション、スポット、または領域がホットとして特定されると、コード分配モジュール210は、一実施形態では、コードのホットなセクションを最適化および/または変換して、最適化/変換されたホットコードを得る。一実施形態では、バイナリ変換コード等の変換および/または最適化コードが、コア202の格納論理に維持される。一例として、バイナリ変換コードは、コア202に維持されているマイクロコードの一部であってよい。変換/最適化コードは、実行されると、コア202での実行用にコードのセクションを変換/最適化する。一実施形態では、コア201、202は、同じISAまたはそのサブセットを認識することができ、ここでの変換/最適化は単に、コードを変換/最適化して、より効率的にコア202で実行できるようにすることであってよい。別の実施形態では、コア201、202が、異なるISAを認識して、ここでは、変換が、コア201が認識可能な1つのISAからのコード領域を、コア202が認識可能な別のISAに変換することを含む。変換/最適化は、変換/最適化コードの実行の観点から説明されているが、任意の変換/最適化コードのメカニズムを利用することができる専用ハードウェアを利用する場合であっても。一実施形態では、ホットコードの特定されたセクションにコア201で遭遇すると、ホットコードその変換されたバージョンが、コア202で実行される。ホットコード領域に遭遇する時を判断するための公知のトリガを利用することができる。高レベルの例のいくつかとして、コード領域に関連付けられている命令アドレスに遭遇/参照すること、コードのセクションをホットコードとして特定する命令をフェッチ/デコード/スケジュールすること、が含まれており、ホットコードの変換されたバージョンを示す命令をフェッチ/デコード/スケジュールすることは、別のコアで実行され、ホットコード領域を示すモニタからの外部トリガに遭遇すること等が含まれている。例では、コード分配モジュール210が、ハードウェア、ソフトウェア、またはこれらの組み合わせで実装されるモニタモジュールを含む。モニタモジュールが、コードのホットな領域を特定している、または、ホットな領域を変換された領域に変換している場合、モニタモジュールは、コードのホットな領域に関する命令アドレスを登録する。登録には、コードの変換された領域の位置との、命令アドレスの関連付けが含まれていてよい。そして、後で命令ポンタプログラムカウンタが、命令アドレスにアクセスすると、登録されている命令アドレスから、コードのホットな領域に遭遇したと判断する。ここでは任意の形態の検知を利用することができるたとえば、遭遇イベントの同期または非同期の割り込み処理スタイル。加えて、ハードウェア、マイクロコード、および/または、ファームウェアが、割り込みのような処理、つまり、ハンドラによりトリガイベントが行われることなくなしに、ホットコードセクションの遭遇を直接処理することができてよい。コア101および102は、マッピング構造等の特定のハードウェア構造を共有して、登録されているアドレスをホットコードとして特定することができる。コア201でホットコードセクションに遭遇すると、ホットコードセクションの変換された、および/または、最適化されているバージョンがコア202で実行される。ホットコードセクションがどのようにコア201で特定または遭遇された場合であっても、別のコアでコードの実行を可能とする任意の公知の方法を利用することができる。一実施形態では、協力モジュールを利用してこのような実行を行うことができる。たとえば、コア201、202は、特定のハードウェア構造を共有したり、および/または、情報共有のための通信チャネルを含んだりすることができる。一例としては、コア101、102が、データキャッシュを共有してよいので、たとえば実行がコア201から202に移る場合などに、データを物理的に移動させるのではなく、共有キャッシュに既に存在させておくことができる。同様に、シャドウレジスタファイル等のレジスタファイルを、一実施形態で、コア201および202の間で共有することができるので、レジスタ状態コンテキストを1つのコアから別のコアへと移す必要がない。この代わりに、レジスタファイルを共有する代わりに、高速インターコネクトを利用して、1つのコアから別のコアへと物理的にコンテキストまたはその一部を移すことができる。これに加えて、あまり頻繁に移されないソフトウェアを利用して移送を行うこともできる。一例として、ホットコードセクションに対する入力値が、コア201からコア202へ返送されて、コア202のホットコードセクションの実行をサポートする。実行の後に、出力値がコア201に戻される。一実施形態では、コードセクションから特定された入出力値のみを移すことができるつまり、部分的なコンテキストスイッチ。この入力値は、ユーザがソフトウェア/コンパイラおよび/またはハードウェア/ファームウェアアルゴリズムによって移すことができてよい。ここで、直接アクセスハードウェアは、レジスタ、バッファ、コア201のその他の構造から入力値を読み出し、コア202に書き込むことができるよう適合されていてよい。この逆に、同じまたは異なるハードウェアを利用して、コア202から値を読み出し、コア201に書き込むことができる。しかし、これら値の特定が非常に面倒である場合には、コア201と202との間に値を提供するために、完全なコンテキストスイッチ、複製、または共有を実行してよい。次に図3を参照すると、コードをコア間に分配して、最大のパフォーマンスおよび節電効果を達成するためのプロセッサの一実施形態が示されている。上述したように、プロセッサ300は、2つのプロセッサコアそれぞれが異なるコアタイプであるを含んでいる。一例では、コア301はネイティブの、アウトオブオーダOOOプロセッサコアであり、コア302がソフトウェア管理されている、インオーダプロセッサコアである。コア301および302は、必須ではないが、異なるISAタイプを認識するものであってよい。実際、コア302は、コア301のISAのサブセットを認識することができる。または、コア302が、コア301のISAと部分的に重なる別のISAを含んでもよい。上述したように、コアまたはプロセッサのデコードハードウェア/ソフトウェアによってコアとプロセッサとはしばしばISAに関連付けられていてよい認識された命令の定義。一実施形態では、モニタモジュール305が、ネイティブのOOOコア301においてネイティブプログラムコード325の実行を監視して、この監視によって、モジュール305は、プログラムコード325のホットな部分/領域327を特定する。モニタモジュールは、ハードウェア、ソフトウェア、またはこれらの組み合わせからなっていてよい。一実施形態では、モニタモジュール305は、実行を監視するハードウェアを含む。一例では、ハードウェアが、マイクロアーキテクチャおよび/またはアーキテクチャフックを含んでたとえば、リタイヤプッシュアウトを計測するためのリタイヤプッシュアウトタグ/カウンタ、命令の数をカウントするための命令カウンタ、実行の長さ全体を計測するための全体トレース実行計測論理、および/または、コードセクションが実行された回数をカウントするための反復カウンタ等、コード325の実行中のパフォーマンス電力メトリックを決定してよい。このタイプのハードウェアは、集積回路/プロセッサの任意の部分たとえばアウトオブオーダコア301内、インオーダコア302内、および、OOOプロセッサコア301にもインオーダプロセッサコア302にも含まれていない集積回路の非関連部分に位置させてよい。別の実施形態では、モニタモジュール305が、実行されると、プログラムコード325の実行を監視して、プログラムコード325のホットな領域327を特定するソフトウェアたとえばモニタコードを含む。図示した例では、プロセッサ300が、格納構造たとえば読み取り専用ROM構造、プログラム可能論理等を含むことで、実行されると監視を行わせるコード、マイクロコード、または機械コードを保持する。しかし監視コードは、コア301、302に関連付けられている任意の機械可読媒体に格納することもできる。実行という用語は、単に従来の実行ユニットによる実行に限られず、プロセッサ300に関連付けられている他のハードウェアまたはプログラム可能論理を含むたとえば、ファームウェアでのマイクロコードの実行。ここでは、実行される監視コードは、ハードウェアが計測可能な反復recurrence、電力、および、パフォーマンスメトリックの同じ監視を実行することができる。一例として、監視ハードウェアおよび/またはコードが、プログラムコードのコードセクションの反復パターンを追跡/判断する。簡単な例として、データ構造が、コードセクションに対する参照コード領域327;たとえば命令アドレスを、命令アドレス/コードセクションがコア301で実行された回数のカウントに関連付ける。ここでカウントは、絶対カウント総カウントまたは一時的カウント単位時間当たりのカウントに関連付けられていてよい。一実施形態では、モニタモジュール305が、プログラムコード325のホットな部分327を特定/検知するよう適合されている。モニタモジュール305は、一例では、OOOプロセッサコア301における実行中にプログラムコード325のホットな部分327の1以上のパフォーマンスメトリックを計測する。そしてモジュール305は、閾値未満のOOOプロセッサコアのパフォーマンスメトリックに応じて、プログラムコード325のホットな領域327を特定する。包括的ではなく、例であるパフォーマンスメトリックのリストには、命令リタイヤプッシュアウト、実行された命令数、コード領域の実行にかかる時間、コード領域が遭遇された/実行された回数、コード領域の実行中に消費された電力量、コード領域の実行中の様々な電力状態で消費される時間、コードセグメントに実行中の熱密度などが含まれる。これら例の1つを利用して、OOOコア301がプログラムコード325を実行すると仮定する。監視コードは、プログラムコード325の領域がコア301上で実行される回数を判断するために実行される。一実施形態で、カウントが閾値になる、またはこれを超えると、モニタモジュール305は、この領域327がホットコードであると特定/判断する。3の閾値が利用される場合、コア302で実行されている監視コードが、コア301で3度、再実行されたホットな領域327を検知して、領域327が、コードのホットな領域であると特定される。反復パターンを判断する具体例から推定してextrapolate、同様のプロセスカウント、閾値に対する比較、および特定が、計測されたパフォーマンスメトリックのいずれかに利用可能であることを示すことができる。さらに、パフォーマンスメトリックの判断は簡単なカウントに限られず、コア、プロセッサ、またはコンピュータシステムにおける実行または節電パフォーマンスを判断する任意の公知のアルゴリズムが含まれてよい。しかし、プログラムコード325内でホットな領域327を特定することは、動的なパフォーマンス監視に限られない。この代わりに、コンパイラまたは静的プログラム分析を利用して、インオーダコア302の実行により適している可能性のあるコードセクションを判断することもできる。たとえば、プログラム分析によって、ホットな領域327が複数回再実行される可能性がある場合を想定する。この発見に応じて、コンパイラまたはユーザは、ホットコードとしてコードのセクションを特定する命令またはデマケーションを挿入してよい。したがい、コア301のデコーダがこの命令に遭遇すると、この領域327が、コア302で実行されるべきホットコードであると認識する。一部の実施形態では、ユーザが、深くプログラムを分析するのではなく、自身のプログラムの知識に基づいてコードのこの領域を特定する。一実施形態では、領域327をホットとして特定すると、コード327が、最適化/変換モジュール310によって最適化され、または変換されて、最適化されたホットコード304が得られる。モニタモジュール305のオペレーション同様に、最適化モジュール310も、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせで実装されてよい。たとえば、変換および/または最適化コードは、コア302、コア301、またはプロセッサ300に関連付けられている構造に格納されてよい。例示すると、バイナリ変換コードが、コア302に関連付けられているファームウェアに格納されている。バイナリ変換コードは、実行されると、コア301のネイティブフォーマットからのホットな領域327を、コア302のフォーマットに変換する。変換は、ISAの間またはその他のフォーマットの間で行われてよく、一方で、最適化には、実行のためにコードを最適化する任意の公知の方法たとえば、OOOコア301のパラレル実行から、コア302におけるシリアル実行に、またはこの逆にコードを最適化する公知の技術が含まれてよい。しかし、ファームウェアのバイナリ変換コードの利用は、純粋に例であり、任意の変換コードまたは最適化コードを、コンピュータの任意の場所に保持することができるたとえばコア302のマイクロコード、または、システムメモリの通常のプログラムコード。そして、最適化コードは、任意の方法で実行されて、ホットな領域327を変換、または最適化して、最適化されたホットコード304を得ることができる。実際、コアのためのコードを変換または最適化する任意の公知の方法または装置たとえば現行のソフトウェア管理されているプロセッサにおけるコード変換のための公知の方法または装置を利用することができる。ソフトウェア、ファームウェア、ハードウェア、またはこれらの組み合わせのいずれを利用するにしても、変換は静的または動的に実行することができる。実際、監視がランタイム中に動的に、または実行前に静的に実行可能であるのと同様に、変換および最適化も実行することができる。コンパイラまたはユーザがホットな領域327を特定する例では、最適化および変換が、その時点で行われてよい実行前。ここで、ホットコード識別子命令を利用して、ホットコード領域327の特定と、最適化/変換されたコード304の位置の特定の両方を行うことができる。しかし、セクション327が実行前または実行中nホットコードとして特定されたか否かに関わらず、一部の実施形態では、最適化および変換が動的に行われるランタイム中に。一実施形態では、ホットな領域327は、他の実行とパラレルに最適化/変換される。一例では、コア302は、領域327のコア301の実行とパラレルに最適化コードの実行を開始する。ここで、モニタモジュール305は、コア301のホットコード領域327の実行を検知して、最適化がコア302で行われるようにする。ホットな領域327からのさらなる命令がコア301でまだ行われている間に、コア302は最適化を開始する。この結果、コア302は、本質的にホットコード327を、コア301におけるホットコード327の実行とパラレルに最適化する。別の例では、コア301は、プログラムコード325の他のセクションを実行し、または、ホットコード327のコア302の最適化とパラレルに他の排他的なコードを実行する。別の実施形態では、ホットな領域327の最適化をシリアルに行う。たとえば、コア301はホットな領域327を実行して、次に、コア301または302が、ホットコード領域327を最適化する。一実施形態では、コード327が、元のメモリ位置に格納されており、オンザフライでコア302によって変換される。しかしほとんどの場合、コードセクション全体を時刻前に変換/最適化するほうが効率がよい。この結果、最適化/変換モジュール310がコアたとえばコア302のためのコードを最適化した後に、最適化されたホットコード304を別の場所に格納しておく。最適化されたホットコード304のための他の位置は、メモリの別の位置たとえば、ホーム、システムメモリ位置であってよい。しかし、ホットコード327は、頻繁な実行に関連付けられている場合も多いので、最適化されたバージョン304はなるべくコア302に近い位置に置いておくほうが有利だと思われる。したがって、示されている実施形態では、コア303が、最適化されたホットコード304を保持しておくためのコードキャッシュ303を含んでいる。コードキャッシュ303は、コア302における別のキャッシュ構造、コア302の共有命令またはデータキャッシュ等の共有キャッシュ構造、または、コア302に関連付けられている他の汎用格納構造であってよい。モニタモジュール305の説明に戻ると、ホットコード領域327に遭遇する一実施形態は、コードセクションに関連付けられている命令アドレスを参照するプログラムカウンタを含む。図示しているように、マッピングモジュール315が、最適化されたホットコードへの参照317と関連付けられているコード領域への参照たとえば命令アドレスを保持する。本質的には、マッピングモジュール315のエントリが、ホットコード領域327を、その最適化されたバージョン最適化されたホットコード304に関連付ける。一例では、参照316が、ホットな領域327に関連付けられているアドレス命令アドレス等を含む。このシナリオでは、コア301がマッピングモジュール315のフィールド316に維持されている命令アドレスに遭遇するとプログラムカウンタがこれを指し示すと、モニタモジュール305が、ホットな領域327に遭遇して、コア302で実行されることを示す。協力モジュール320は、上で簡単に説明しており、後で詳述するが、次に、データおよび/またはコンテキストの、実行のためのコア302への移動を促す。上述した例におけるホットな領域327に遭遇した、またはコア302で実行されるという判断は、参照316に対するもののみである。次にフィールド317のフィールド316への関連付けを利用することで、領域327の最適化されたホットコードバージョン304がどこに位置しているかを迅速に判断することができる。この結果、フィールド317は、最適化されたホットコード304の位置に対するいずれかの参照を含んでよい。これらの参照のいくつかの簡単な例には、最適化されたコード304を維持するコードキャッシュ303のエントリのアドレス、コードキャッシュ303の最初から、最適化されたホットコードを維持しているエントリ304へのオフセット、および、エントリ304に関連付けられている物理的またはリニアアドレスが含まれる。マッピングモジュール315は、簡単なテーブル構造で示されており、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせで実装および/または維持されてよい。しかし、ある位置を別の位置に関連づけるための任意の公知の方法を、ホットコード327をその最適化されたバージョンに関連付けるために利用することができる。特に例示はしてないが、モニタモジュール305の部分と、マッピングモジュール315とを組み合わせて、ネイティブコード327をコア301で実行するのではなく、最適化されたホットコード304をコア302で実行することを示すトリガモジュールが形成される。一例では、コア301のプログラムカウンタが次の命令アドレスに移動されると、トリガハードウェアが、マッピングハードウェアテーブル315に格納されている参照との対照で、そのアドレスをチェックする。ここで、プログラムカウンタが、フィールド316に維持されているコード領域327を参照する命令アドレスを指し示していると想定する。次に、トリガハードウェアが、マッピングテーブル315のエントリに基づいて、コード領域327のための最適化されたコード領域304が存在していることを示す。この結果、コア301のコード領域327の実行を無視することができる最適化されたバージョンが既に存在しており、コア302で実行されるから。一実施形態では、コア301が、コア302が最適化されたコードの実行を完了するまで、実行を停止するストップする、または、低電力状態に遷移する。しかし、これは、プロセッサ300の処理容量の完全利用にならない場合もある。したがって別の実施形態では、最適化されたホットコード304がコア302で実行されている間に、コア301が、別のソフトウェアスレッドプログラムコード325以外のコードの実行をインタリーブする。また別の例では、コア301が、投機的にプログラムコード325の他の部分を実行してよく、これは、本質的に、実行のランアヘッドヘルパスレッドrunaheadhelperthreadを実行したり、または、コード領域327に依存しないコード325の他の部分をアウトオブオーダで実行したりする。協力モジュール320は、一実施形態では、コア301、302の間に協力機能を提供する。一番簡単な例では、協力モジュール320が、情報を移すためのコア301、302の間のインターコネクトを含んでいる。しかし別の実施形態では、協力モジュールが、上述した協力を促すために、個々のコア専用であってもこれらの間で共有されていてもよい他のハードウェアを含んでいる。たとえばコア302は、コア301から302へのレジスタ状態の完全なコンテキストスイッチが、最適化されたホットコード304がコア302で実行されているときに実行される必要がないように、コア301のシャドウレジスタファイルを共有してもよい。この代わりに、コア302が、この例のシャドウレジスタファイルに直接アクセスできる。しかし協力モジュールは、共有構造および/またはインターコネクトのみに限定はされない。実際、協力モジュール320は、レジスタ、格納構造、および両方のコア301、302のバッファに対して直接読み書きアクセスを提供するために、ハードウェア、ファームウェア、ソフトウェア、またはこれらの組み合わせを含んでよい。この結果、協力モジュール320は、一実施形態では、コア301からコア302への最適化されたホットコードの実行に必要なデータ/レジスタ値を移すことができる。そして、コア302からコア301に結果を戻して、後で、コア301で適切に実行させることもできる。モニタモジュール305は、主に、ネイティブコア301での実行監視を例にとって説明されたが、一実施形態では、モニタモジュール305が、コア302における最適化されたコードの実行を監視することもできる。この結果、モニタモジュール305は、コア302での最適化されたバージョン304のパフォーマンスと、コア301のコードセクション327のパフォーマンスとを比較することができる。さらに、コア302のパフォーマンスがコア301のパフォーマンスより低い場合、または、コア302におけるパフォーマンス利得が、電力消費の増加に比べて小さい場合には、領域327をホットコードとして特定するための決定を逆にしてよい。一例では、この決定を示すマッピングモジュール315のエントリが割り当て解除されたり無効化されたりして、次にコア301がホットコード327に遭遇したときに、モニタモジュール305が、参照316を検知せず、領域327の最適化されたホットコードバージョンがコア302で実行されるべきであると示さないようにする。本質的には、逆の決定によって、前に特定された領域327が、アウトオブオーダコア301に戻される。このパフォーマンス比較をさらに示す具体例として、コード領域327が、高い反復パターンと高い命令実行カウントに基づいて、ホットコードとして特定されると想定する。この結果、コード327が、コア302に存在しているバイナリ変換コードにより最適化され、最適化されたコード304が得られる。最適化されたコード304をコードキャッシュ303に格納するとき、マッピングテーブル315のエントリを作成して、コード領域327を、最適化されたバージョン304に関連付ける。コア301が、次に、フィールド316の参照に合致する参照に遭遇すると、最適化されたコード304の実行が、コア302でトリガされるコア301のコード領域327で実行される代わりに。協力モジュールは、転送、共有、またはコンテキストスイッチによって、コア301からコア302に適切な値を提供する点に留意されたい。コア302がホットコード304を実行している間に、同じパフォーマンスメトリック命令実行カウントをモニタモジュール305によって追跡する。命令実行カウントがコア301で実行されたコード領域327未満である場合、領域327をホットコードとして特定する現状維持を将来的も続ける。しかし、コア302での命令実行カウントのほうが長い場合、または顕著な電力増加が検知された場合には、上述したように、領域327をホットコードとして特定する判断を逆にすることができる。コア301および302の間に通信を提供するのに加えて、協力モジュール320は、さらに、それぞれ異なるタイプの複数のコアを管理する他の特徴部を含んでよい。第1の例として、電力マネージャが、両方のコア301および302が同時に最大電力で動作しないようにする電力アルゴリズムを実装する。しかしこの例は純粋な例である。他の電力アルゴリズムでこのような最大のオペレーションをさせることもできる。電力について考えなければならない別のこととして、コア302が、コア301における実行監視中に、最大を下回る電力状態に存在している低電力状態場合もある、ということがある。たとえば、コア301が、自身の監視を実行するメカニズムに関連付けられている場合には、コア302は、実行するべきコードの最適化されたバージョンが得られるまでは、完全に電源が入ったpoweredup状態にする必要はない。この結果、実行に必要となるまでは、コア302を停止させることで潜在的に節電することができるようになる。逆に、コア302が最適なホットコードを実行している間は、コア301への電力供給を停止させてよいたとえばACPI低電力状態またはスリープ状態といった、最大未満の電力状態にする。コア間を動的に実行切り替えするときに、1コードの任意のセグメントのために最も適切なコアをタイムリー且つ正確に予測すること、および2コア間で実行を効率よく移動させること、という2つの課題がある。一実施形態では、第1のコアでのプログラム実行がたとえば、コード領域で分析されるILPに基づいてランタイムソフトウェアおよび/またはハードウェアにより特定されてよく、次に、現在のコアのパフォーマンスメトリックおよび/または統計データを、モニタモジュール305で継続的に収集して、プログラムコードの実行を第2のコアにスイッチするべきときを予測する。この方法は図4に示されている。この方法は、1つのコアからのデータを利用して、他のコアのパフォーマンスを予測するので、一実施形態では、この方法はシングルコア予測アルゴリズムと称される。図4に戻ると、第1のタイプの第1のコアアウトオブオーダコア等と、第2のタイプの第2のコアインオーダコア等との間でコードを分配して、最大のパフォーマンスおよび節電効果を達成するための方法400のフロー図の一実施形態が示されている。図4のフローは、実質的にシリアルで描かれているが、フローは、異なる順序で実施されても、パラレルに実施されてもよい。さらにフローそれぞれを、ハードウェア、ファームウェアを利用して、またはプログラムコードに実行によって実施されてもよい。プロセッサのアウトオブオーダOOOプロセッサコアでのプログラムコードの実行を監視する。一実施形態では、プログラムコードに対する言及は、1動的であっても静的であっても、他のプログラムコードをコンパイルするためのコンパイラプログラムの実行、2オペレーティングシステム、ハイパーバイザ、アプリケーションコードその他のソフトウェアプログラム等のメインプログラムの実行、3メインプログラムコードに関連付けられている、ライブラリ等の他のプログラムコードの実行、4メインプログラムに直接関係しなくてよい他のプログラムコードたとえばヘルパースレッドその他のタスク、または5これらの組み合わせのことであってよい。コンパイラは、対象テキスト/コードにソーステキスト/コードを変換するプログラムまたは一組のプログラムを含んでよい。通常は、コンパイラによるプログラム/アプリケーションコードのコンパイルは、複数フェーズで行われ、高レベルプログラミング言語コードを、低レベルマシンまたはアセンブリ言語コードに変換するように渡すことができる。しかし、シングルパスコンパイラは、単純なコンパイルに利用することもできる。コンパイラは、任意の公知のコンパイル技術を利用して、任意の公知のコンパイラオペレーションを行うことができる語彙分析、前処理パース、意味分析、コード生成、コード変換、およびコードの最適化等。より大きなコンパイラが、しばしば、複数のフェーズを含むことができるが、1フロントエンド一般的に構文処理、意味処理、および一部の変換/最適化を行ってよい場所、2バックエンド一般的に、分析、変換、最適化、およびコード生成を行ってよい場所という2つの一般的なフェーズ内に含まれている。一部のコンパイラは、ミドルエンドについて言及しているが、このミドルエンドは、コンパイラのフロントエンドとバックエンドとの間の境界の曖昧なところを表している。この結果、挿入、関連付け、生成、その他のコンパイラのオペレーションに対する言及は、上述したフェーズまたはパスのいずれか、および、コンパイラの任意の他の公知のフレーズまたはパスで行われてよい。一実施形態では、モニタモジュール305のプログラムコードの実行監視が、プログラムコード内でのコードセグメント/領域の実行回数を追跡することを含む。コード領域は、命令/コードを分類する任意の公知の方法で決定されてよい。一例として、コードセクションに関連付けられている命令アドレスがOOOコアのプログラムカウンタにより参照されるたびに、反復カウントを増分させる。コードセクションの反復カウントが閾値を超えると、一実施形態では、このコードセクションをホットコードとして特定する。反復パターンの判断に関連して、または別個に、プログラムコードの実行監視には、コードセクションに関するパフォーマンスメトリックの決定/追跡が含まれてよい。上述したように、例であるパフォーマンスメトリックには、命令リタイヤプッシュアウト、実行された命令数、コード領域の実行にかかる時間、コード領域が遭遇された/実行された回数、コード領域の実行中に消費された電力量、コード領域の実行中の様々な電力状態で消費される時間、コードセグメントに実行中の熱密度が含まれてよい。しかし、プロセッサ実行に関する任意の公知のメトリックまたはメトリックの組み合わせが、プログラムコードの実行中に監視されてよい。ブロック402で、プログラムコードを第1のコアで実行してよい。一実施形態では、第1のコアが、狭帯域のアウトオブオーダコア等の第1のタイプであってよい。ブロック404で、第1のコアがプログラムコードを実行する際に、第1のコアのパフォーマンスを監視してよい。ブロック406で、パフォーマンスの統計データを収集してよい。一実施形態では、統計データには、分岐ミス率、キャッシュミス率等が含まれてよい。一実施形態では、パフォーマンスの監視および統計データの収集が、モニタモジュール305により実行されてよい。ブロック408で、第2のコアにおけるプログラムコードの実行のパフォーマンスが、第1のコアにおけるプログラムコードの実行のパフォーマンスおよび統計データに少なくとも一部基づいて、予測されてよい。一実施形態では、第2のコードが、第2のタイプであってよいたとえば広帯域のインオーダコア。代わりに、第1のタイプが、広帯域のインオーダコアであってよく、第2のタイプが、狭帯域のアウトオブオーダコアであってよい。一実施形態では、予測が、予測_パフォーマンスと称される関数として実装されてよい。ブロック410で、第2のコアによるプログラムコードの実行について予測されたパフォーマンスが、第1のコアによるプログラムコードの実行について監視されたパフォーマンスよりも良好な場合には、以下の動作を実行してよい。ブロック412で、第2のコアを、低電力またはスリープ状態から立ち上げてよいpoweredup。立ち上げ中に、第1のコアが、プログラム実行を続ける。ブロック414で、プログラムコードの実行が、第1のコアから第2のコアにスイッチされてよい。ブロック416で、第1のコアが、スリープ状態へと電力を落とされるpowereddown。第2のコアの予測されたパフォーマンスが第1のコアのものよりよくない場合には、第1のコアにおけるプログラムコードの実行を続けてよい。後で方法を反復するときに、方法における第1のコアおよび第2のコアの位置を交換してもよいたとえば、第2のコアがまず実行されて、第2のコアのパフォーマンスが監視され、第2のコアの統計データを収集して、第1のコアのパフォーマンスを予測する、等が行われてよい。一実施形態では、ブロック404から416が、コード分配モジュール210により実行されてよい。予測_パフォーマンス関数コア数、パフォーマンス_コア1、統計データ_コア1で、現在のコアの実行パフォーマンスおよび統計データである、パフォーマンス_コア1、および統計データ_コア1を利用して、第2のコアにおける実行のパフォーマンスを予測する。予測されたパフォーマンスが現在のコアよりも高い場合、実行を他のコアに切り替える。この方法は、現在のコアのパフォーマンス情報を利用して、他のコアのパフォーマンスを予測することができるという想定に基づいている。直感的には、過度のキャッシュ/分岐ミスのあるプログラムの実行は、後の命令をアウトオブオーダで実行すると、ミスのレイテンシーを隠すことができることから、狭帯域のアウトオブオーダのコアでのパフォーマンスのほうが良好になるはずである。他方で、高い命令レベルのパラレリズムILPおよび低キャッシュ/分岐ミスのプログラムは、実行帯域幅が高いことから、広帯域のインオーダコアでより効率的に実行されるはずである。一実施形態では、予測_パフォーマンス関数を定義するためには、まずc1、、cnというn個のコードを第1のコアおよび第2のコアの両方で実行して、2つのコアにおけるそれぞれのパフォーマンス情報p11、p12、、p1np21、p22、、p2nおよび、統計データs11、s12、、s1ns21、s22、、s2nを収集してよい。そして、最適に適合する関数Fを見つけるための1つのやり方としては、Fp11、s11、Fp12、s12、、Fp1n、s1n、-p21、p22、、p2nおよびFFp21、s21、Fp22、s22、、Fp2n、s2n、-p11、p12、、p1nが最小限になるものを見つけるやり方がある。最適な適合の標準誤差が小さい場合には、Fを、予測_パフォーマンスの関数として利用することができる。しかし標準誤差が大きい場合には、予測精度を高めるために、より多くのパフォーマンスパラメータを見つける必要があるだろう。シングルコアの予測法の1つの利点は、決定に際して他のコアに関するパフォーマンスおよび電力オーバヘッドを考慮せずに、現在のコア実行統計データのみを利用して、他のコアのパフォーマンスを予測することができる点である。しかしこの方法は、2つのコアのパフォーマンスが密に関連しあっていることが前提である。一部の環境/構成においては、2つのコアのパフォーマンスが、緩い相関性しか有さず、良好な適合関数が存在しない場合もある。したがって、この場合は、より一般的な方法をとると好適だろう。別の実施形態では、デュアルコア予測方法により、短期間に2つのコアに観察されるパフォーマンス情報を利用して、コアの切り替えが予測される。具体的に、予測は、2つのコアのパフォーマンスをサンプリングおよび比較するために定期的な間隔で実行されて、異なるコアに実行をスイッチすべきかを決定してよい。各予測は、2つのコアのスイッチに関している。つまり、第1のスイッチは、他のコアからパフォーマンス情報を取得するために行われ、第2のスイッチは、他のコアのパフォーマンスが、第1のコアのものより劣るために、実行を第1のコアに戻すべき場合に行われる。第1のコアのスイッチは、他のコアを立ち上げて、実行のためにそのマイクロアーキテクチャ状態をウォームアップして、第2のコアのスイッチは、コアの電力を落とすことだけに関している。コアのスイッチオーバヘッドを低減させるために、予測は2つのオペレーションつまり継続用の予測Pcontオペレーションおよびスイッチのための予測Pswitに分けられてよい。Pcontオペレーションは、現在のコアで収集されたパフォーマンス情報を、2つのコアの前のパフォーマンス情報と比較して、実行を現在のコアで続けるべきかを判断する。Pcontオペレーションが、実行を現在のコアで続けるべきではないと予測している場合には、Pswitオペレーションにより、他のコアを起動して、他のコアを短期間実行させ、2つのコアのパフォーマンス情報を比較して、他のコアに実行を移すべきかを判断する。Pcontが同じコアで実行され続ける期間が長くなりすぎないように、パラメータKを導入して、PswitオペレーションがKを超える回数、立て続けにinarow省かれないようにする。さらに、Pswitオペレーションを省くたびに、前のパフォーマンスを、インフレーション係数でインフレーションして、次のPcont期間で、Pswitオペレーションを省くことが困難になるようにしてよい。デュアルコア予測プロセス500が図5に示されている。一実施形態では、Sが、サンプリング間隔でありたとえば予測の間のサイクル数、Mが各コアでのパフォーマンスを収集するためのサンプル長たとえばサイクル数であり、PUが、第2のコアを立ち上げるためのサイクル数であり、IPCが、サイクルごとの命令数であり、Kは、最大継続数Kは自然数であるであり、Nは、継続数最初は0に設定されているであり、Prev_IPCが、前のIPC最初はMAX_FLOATに設定されているである。一実施形態では、S、M、PU、K、およびインフレーション係数が、適切な値に設定されていてよい。ブロック502で、プログラムコードが、S個のサイクルのサンプリング間隔分、第1のコアで実行されてよい。一実施形態では、第1のコアが、第1のタイプであってよいたとえば狭帯域のアウトオブオーダコア。ブロック504で、プログラムコード実行開始からSMサイクルが終わる前に、PUサイクル分、第2のコアの立ち上げを、信号で指示してよい。一実施形態では、第2のコアが、第2のタイプであってよいたとえば広帯域のインオーダコア。この代わりに、第1のタイプが、広帯域のインオーダコアであって、第2のタイプが、狭帯域のアウトオブオーダコアであってのよい。ブロック506で、第1のコアIPC1のサイクルごとの命令数を、M個のサイクルの間収集してよい。一実施形態では、パフォーマンスの監視と、統計データの収集とを、モニタモジュール305またはコード分配モジュール210のいずれかで実行してよい。次に、第1のコアPcontでの継続実行の予測を以下のように行ってよい。ブロック508で、継続数Nが、最大継続数Kを下回る場合であって、第1のコアIPC1のサイクルごとの命令数が、サイクルごとの前の命令数より大きい場合Prev_IPCであり、最初は最大値に設定されているには、ブロック510、512、および514を実行してよい。この場合には、第1のコアから第2のコアへのスイッチを行わない。ブロック510で、第2のコアの電力を落とすよう信号で指示してよい。ブロック512で、サイクルごとの前の命令数Prev_IPCが、Prev_IPCに、インフレーション係数を乗じた数に設定されてよい。処理は、プログラムコードを第1のコアで継続実行して継続される。継続数Nが、最大継続数K以下である場合、または、第1のコアのサイクルごとの命令数IPC1が、サイクルごとの前の命令数Prev_IPC以下である場合にはブロック508、ブロック516、518、および520を実行してよい。この場合には、第1のコアから第2のコアへのスイッチを行ってよい。次に、第1のコアから第2のコアへの実行のスイッチのための予測Pswitを以下のように行ってよい。ブロック516で、カウンタNが0に設定されてよい。ブロック518で、プログラムコードの実行を第1のコアから第2のコアにスイッチしてよく、第2のコアのサイクルごとの命令数IPC2を収集してよい。次に、チェックを行って、スイッチが意味のあるものであったかを検証する。ブロック520で第2のコアのサイクルごとの命令数IPC2が、第1のコアのサイクルごとの命令数IPC1未満である場合に、プログラムコードの実行を第2のコアから第1のコアにスイッチして戻すブロック522。サイクルごとの命令数以外の別のパフォーマンスメトリックを利用する場合に、第2のコアにおけるパフォーマンスが第1のコアにおけるパフォーマンスより良くない場合には、プログラムコードの実行が、第2のコアから第1のコアにスイッチして戻されてよい。第2のコアの電力を落とすよう、次に信号で指示してよいブロック524。しかし、ブロック520で、第2のコアのサイクルごとの命令数IPC2が、第1のコアのサイクルごとの命令数IPC1未満でない場合には、コアのスイッチが意味のあるものであることになる。サイクルごとの命令数以外の別のパフォーマンスメトリックを利用する場合に、第2のコアにおけるパフォーマンスが第1のコアにおけるパフォーマンス以上である場合には、コアのスイッチが意味のあるものであることになる。ブロック528で、第1のコアの電力を落とすよう、信号で指示してよい。いずれの場合であっても、一実施形態では処理がブロック530で、サイクルごとの前の命令数Prev_IPCを、IPC値の平均値IPC1IPC2/2に設定して続けられる。ここでは算術平均を平均値として利用しているが、幾何平均、調和平均、およびその他のいずれの平均を利用して、2つのIPC値の平均を提示してもよい。このようにして、第1のコアの電力が落とされた状態で、第2のコアに処理を行うことができる。後での方法の反復において、方法における第1のコアおよび第2のコアの位置を交換してもよいたとえば、第2のコアがまずSサイクルについて実行されて、第1のコアの立ち上げを信号で指示して、第2のコアのパフォーマンスをM個のサイクル分監視して、第2のコアについての統計データを収集する、など。一実施形態では、少なくともブロック504から530までを、コード分配モジュール210により実行してよい。コアのスイッチには、1低電力状態であってよい他のコアの起動、2x86レジスタ状態を他のコアに移す、3頻繁にアクセスされたデータを他のデータキャッシュに移す、4命令キャッシュ、分岐予測状態、および他のコアの他の状態をウォームアップする、といったいくつかのオーバヘッドが関係する。他のコアを起動するまたは立ち上げるときのレイテンシーは、他のコアの低電力状態に依存している。一部の実施形態では、コアが停電量C2状態にあるときつまり通常の動作出力の30までを消費するとき、コアの電力を通常の動作速度C0状態にまで上げるためには、5000サイクル程度が必要となるだろう。コアが、より深い電源停止状態C6にある場合にはつまり、動作電力の10未満を消費しているとき、一実施形態では、再起動wakeupするために20万サイクル程度が必要となるだろう。立ち上げは時間がかかるが、他のコアの実行とパラレルに実行することができる。例えば、一実施形態では、第1のコアがPswit/Pcont期間に入る前に、第1のコアまたはその他のモジュールが、信号を第2のコアに送って、立ち上げを開始させてもよい。第1のコアの予測期間が終わるときには、第2のコアが既に立ち上がっており、プログラムコードの実行を続けることができてもよい。この早期に立ち上げる戦略をもってすれば、立ち上げのレイテンシーは、エネルギー消費量を増加させはするかもしれないが、コアのスイッチのレイテンシーにもパフォーマンスにも影響しない。一実施形態では、レベル2L2キャッシュが2つのコアで共有されていても、データおよび命令キャッシュのウォームアップに1万サイクル程度かかる。さらに、現代のハイブリッド分岐予測器においては、分岐予測器をかなり急速にウォームアップすることができる。コアの立ち上げが、PUサイクルかかり、分岐予測器およびL1キャッシュのウォームアップがWUサイクルかかると想定する。図6は、コアスイッチ動作とオーバヘッドとを示している。図6における時間の表示は例示にすぎず、様々な段階の間の実際の特定のタイミング関係を伝える意図は持たない点を理解されたい。第1のコア601がPcont期間に入る前に、第1のコアは、第2のコア602に立ち上がるよう信号で指示する603。第1のコアが自分のPcontオペレーションを終了した後で、コアスイッチが必要となるかもしれないと判断すると、プログラムコード実行を第2のコア604にスイッチさせてよい。この時点では、第2のコアが既に立ち上がっており、WUサイクル605分、ウォームアップを開始する。ウォームアップ期間の後に、第2のコアは短期間たとえばMサイクル作動して、自身のパフォーマンスデータ606を収集する。ここで、第2のコアのパフォーマンスが第1のコアのパフォーマンスより良好なので、第2のコアが第1のコアに対して電力を落とすようPD指示して607、第2のコアでの実行を続ける、と想定する。次のPcont期間の最後に近づくと、第2のコアは、第1のコアに立ち上がるよう信号で指示する608第2のコアが自身のPcont期間を終えた後で、第2のコアが実行を継続すべきであると認識すると、第2のコアは第1のコアに対して、電力を落とすようして609、第2のコアでのプログラムコードの実行を続けるよう信号で指示する。ネイティブコアを、異なる共同設計されたコアに連結させる結果、ここで説明する動的なコア選択技術を利用した場合に1つのアプリケーション内であっても、電力および実行の利点のうち最良のものが潜在的に得られる。例えば、アウトオブオーダコアおよびソフトウェア管理されているインオーダコアを利用すると、ソフトウェア管理されているコアでは非効率なコードが、アウトオブオーダコアに移される。またこの逆に、アウトオブオーダコアでは非効率なコードが、ソフトウェア管理されているコアに移される。ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせによって、ネイティブコードのパラレル実行、ホットコード検知、およびホットコード最適化を効率的に管理することができるようになり、且つ、複数のスレッドの個々のセクションを、アウトオブオーダおよびインオーダ共同設計コアの間で、パイプライン方式で効率よくインタリーブすることができるようになる。この結果、最大パフォーマンスが得られ、且つ、異なる電力効率技術たとえば、一部の実装例で、インオーダコアにおける実行中に、アウトオブオーダコアを低電力状態に置く等によってより良い電力パフォーマンスを達成することができる。ここで利用するモジュールは、任意のハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせであってよい。別個に例示されているモジュール間の境界は、通常変化して、潜在的に重なっている場合もある。例えば第1および第2のモジュールは、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせを共有して、一方で、一部の独立したハードウェア、ソフトウェア、またはファームウェアを維持している可能性があってもよい。一実施形態では、論理という用語を利用する場合、ハードウェアたとえばトランジスタ、レジスタ、またはその他の、プログラム可能な論理デバイス等のハードウェアが含まれてよい。しかし別の実施形態では、論理にはさらに、ハードウェアと統合されたソフトウェアコードが含まれるたとえばファームウェアまたはマイクロコード。ここで利用する値には、任意の公知の数、状態、論理状態、またはバイナリ論理状態の表現が含まれている。しばしば、論理レベル、論理値またはロジック値の利用は、1および0で表されることがあり、これらは単にバイナリ論理状態を表しているに過ぎない。たとえば1は、論理レベルがハイである場合を示し、0は、論理レベルがローである場合を示す。一実施形態では、記憶セルたとえばトランジスタまたはフラッシュセルが、1つの論理値または複数の論理値を維持することができる。しかし、コンピュータシステムでは値の他の表現を利用してきた。例えば十進数の10は、二値法で1010で表され、16進法でAで表される。したがって、値は、コンピュータシステムが維持可能な情報の任意の表現形態を含む。さらに、状態は、値または値のある部分によって表現されてよい。一例では、第1の値たとえば論理1は、デフォルトまたは初期状態を表してよく、第2の値たとえば論理0は、デフォルトではない状態を表してよい。加えて、リセットおよびセット設定という用語は、デフォルトと、更新された値または状態をそれぞれ示す。例えば、デフォルト値は、潜在的に、高い論理値つまりリセットを示し、更新された値は、潜在的に、低い論理値つまりセットを含む。値の任意の組み合わせを利用することで、任意の数の状態を表すことができる。上述した方法、ハードウェア、ソフトウェア、ファームウェア、またはコードの実施形態は、処理エレメントが実行可能な機械可読媒体に格納されている命令またはコードにより実装されてよい。機械可読媒体は、機械たとえばコンピュータまたは電子システムが可読な形態で情報を提供つまり格納および/または送信することができる任意のメカニズムを含む。たとえば、機械可読媒体は、ランダムアクセスメモリRAMたとえばスタティックRAMSRAMまたはダイナミックRAMDRAM、ROM,磁気または光学記憶媒体、フラッシュメモリ素子、電気記憶素子、光学記憶素子等を含む。本明細書全体において、1実施形態または1つの実施形態という言い回しは、その実施形態で記載される特定の特徴、構造、または特性が、本発明の少なくとも1つの実施形態に含まれていることを示す。したがって1実施形態または1つの実施形態という言い回しが本明細書の随所にみられても、これらは必ずしも全てが同じ実施形態のことを意味しているわけではない。さらに、特定の特徴、構造、または特性は、1以上の実施形態において、任意の適切な方法で組み合わせることができる。前述した明細書では、具体的な実施形態を参照しながら詳細な記載を行った。しかし、添付請求項に示されている本発明の広義の精神および範囲を逸脱せずに、様々な変形例および変更例が可能である。したがい、明細書および図面は、限定ではなく例示として受け取られたい。さらに、実施形態の前述した用途および例である他の用語は、必ずしも同じ実施形態または同じ例を示している場合ばかりではなく、異なる別個の実施形態のことである場合もあれば、同じ実施形態を示している場合もある。"