JP2007506199A - マルチスレッディングのスレッド管理の方法および装置 - Google Patents

Abstract

【課題】マルチスレッディングのためのスレッド管理の方法および装置を提供する。
【解決手段】一実施形態において、典型的な処理は、データ処理ユニット中の一つ以上の実行ファイルを有するコードの編集中に、最も下部の順を有するカレントスレッドを選択する段階と、カレントスレッドから生成された一つ以上の子スレッドに割り当てるリソースを決定する段階と、カレントスレッドと当該カレントスレッドの一つ以上の子スレッドとの間のリソースコンフリクトを避けるために、カレントスレッドの一つ以上の子スレッドに割り当てられたリソースに考慮して、カレントスレッドにリソースを割り当てる段階とを備える。他の方法および装置もまた開示されている。

Description

本発明の実施形態は情報処理システムに関し、特に、マルチスレッディングのためのスレッド管理に関する。

メモリ待ち時間は、現在のプロセッサの高い性能を達成するに際して重大なボトルネックとなっている。アプリケーションのメモリアクセスパターンの予測が困難であり、ワーキングセットがかなり大きくなっているために、今日の多くの大きいアプリケーションはメモリ集約的である。キャッシュデザインの向上およびプリフェッチ技術における新しい開発にもかかわらず、メモリのボトルネック問題は依然として続いている。この問題は、従来のストライドベースのプリフェッチ技術に逆らう傾向にある、ポインタ集中のアプリケーションの実行の際により悪化する。

解決策の一つは、一つのプログラムで別のプログラムからの有用な命令の実行と同時にメモリ区画を重ね合わせることであり、その結果、効果的に総合的な処理能力に関して、システムの性能が向上する。単一のプロセッサ上におけるマルチタスクの作業付加のスループットを向上することは、同時マルチスレッディング（ＳＭＴ）技術の出現の後にある主要な動機である。ＳＭＴプロセッサは、複数のハードウェアコンテキスト、または論理プロセッサ（または、ハードウェアスレッドと称される）から、同じサイクルのスーパースカラプロセッサの機能的ユニットに指示を出すことができる。ＳＭＴは、各サイクルの間の独立したスレッド間で、本来の並列処理の利用を通してアーキテクチャに利用可能な全体的な並列処理の指示レベルを増加させることにより、より高い総合的な処理能力を達成する。

ＳＭＴはまた、マルチスレッドのアプリケーションの能力を向上させることができる。しかしながら、ＳＭＴは、待ち時間を減少させる観点から見ると、シングルスレッドアプリケーションの能力を直接的に向上させるものではない。これまでのＰＣ環境においてデスクトップアプリケーションの大多数はシングルスレッドであるので、仮にそしてどのように、待ち時間を減少させることによりシングルスレッドのコードのパフォーマンスを強化することにより、ＳＭＴ資源を利用しうるのかを調査することは重要である。

更に、現在のコンパイラは典型的には、生成したスレッドのための資源を自動的に割り当てることができない。

本発明は、以下に述べる記述および本発明の実施形態を図示した添付図面を参照することにより最もよく理解されるであろう。

マルチスレッドシステムのコンパイラ生成ヘルパースレッドの方法および装置について述べる。一実施形態によれば、例えば、インテル社から入手できるインテルペンティアム（登録商標）４ハイパースレッドシステムのようなマルチスレッドシステム上で、スレッドベースのプリフェッチヘルパースレッドを実行するオートヘルパーとしても呼ばれるコンパイラがスレッドを実行する。

一実施形態によれば、コンパイラは、ハイパースレッドプロセッサのためにヘルパースレッドの生成を自動化する。最小限のコミュニケーションオーバヘッドが流入する一方で、技術は、適時で効果的なデータプリフェッチングを達成するために実行され得る、最小限サイズのヘルパースレッドの特定および生成に注目する。ランタイムシステムは、また、ヘルパースレッドおよびスレッド間の同期化を効果的に管理するために実行される。その結果、ヘルパースレッドは適時に、順次ポインタ集中アプリケーションのためのプリフェッチを発行できる。更に、レジスタコンテキストなどのハードウェア資源が、コンパイラ中においてヘルパースレッドによって管理されてもよい。具体的には、レジスタセットは、静的または動的に主要スレッドとヘルパースレッド間、および多重ヘルパースレッド間に分割されてよい。結果として、スレッドのためのメモリを介したリブ−イン／リブ−アウト（ｌｉｖｅ−ｉｎ／ｌｉｖｅ−ｏｕｔ）レジスタコピーは回避されうるし、コンパイラが資源を使い果たしたとき、または所定の主要スレッドイベントのまれなケースが生じるランタイムにおいて、スレッドはコンパイル時間で破棄されうる。以下の記述では、多数の特定の記述が説明されている。しかしながら、本発明の実施形態がこれらの特定の記述なしに実施されうることが理解される。他の場合においては、本記述の理解をあいまいにしないために、既知の回路、構造、及び技術の詳細については示していない。

以下、詳細な記述のいくつかの部分は、アルゴリズム及びコンピュータメモリ中のデータビット上における操作の記号による表現の観点で示されている。これらのアルゴリズム的な記述及び表現は、他の当業者にそれらの働きの要旨を最も効果的に伝えるために、データ処理技術の当業者によって使用される。本明細書におけるアルゴリズムとは、一般的に、所望の結果に導く演算の、自己矛盾のない手順として考えられる。演算は、物理量の物理的な取り扱いを必要とするものである。通常、必ずしも必要ではないが、これらの物理量は、格納することができ、転送することができ、結合することができ、比較することができ、及びその他の操作をすることができる、電気的、または磁気的な信号の形式をとる。時には、主に一般的に使用されているという理由で、これらの信号を、ビット、数値データ、要素、符号、文字、語、数字などとして参照することが有用であることが証明されている。しかしながら、これら及び類似の用語の全てが適切な物理量と関連付けられており、これらの物理量にラベルとして適用しているのは単に便利だからであるという点は念頭においておくべきである。

また、特に詳しく述べない限り、以下の説明からも明らかなように、記述全体を通して、「処理する」、または「コンピュータで計算する」、または「計算する」または「決定する」または「表示する」などのような用語を用いての記載は、、コンピュータシステム、あるいは類似のデータ処理装置の動作、およびプロセスを言及している。データ処理装置は、コンピュータシステムのレジスタ、並びにメモリ内の物理（例えば、電子的な）量として表されるデータを扱い、そして、コンピュータシステムのレジスタ、およびコンピュータシステムのメモリあるいはレジスタ、若しくは他の情報記憶装置、送信装置、あるいは表示装置内の物理量として同様に表される他のデータ内へ転送する。

本発明の実施形態は、また、ここで述べる操作を実行する装置に関する。装置は、必要な目的に応じて特に構成されていてよく、あるいは、選択的に起動する、または、コンピュータに格納されているコンピュータプログラムによって再構成される一般的な目的のコンピュータで構成してもよい。そのようなコンピュータプログラムは、コンピュータで読み込み可能な記憶媒体、例えばフロッピーディスク（登録商標）、光ディスク、ＣＤ−ＲＯＭ、そして、磁気光学ディスク、リードオンリーメモリ（ＲＯＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）のようなランダムアクセスメモリ（ＲＡＭ）、消去可能なプログラマブルＲＯＭ（ＥＰＲＯＭ）、電気的に消去可能なプログラマブルＲＯＭ（ＥＥＰＲＯＭ）、磁気あるいは光カード、あるいは他の型の電子情報を格納するのに適した媒体のような、これらに限定はされないが、どのような種類のディスクに格納されていてもよく、上記記憶媒体の各々はコンピュータバスに接続されている。本明細書で示すアルゴリズムおよび表示部は、本来的にはいかなる特定のコンピュータ又は他の装置とも関係しない。様々な一般的な目的のシステムが、本明細書の教示に関連付けられたプログラムを用いて使用されてよく、あるいは、方法を実行するためのより特定化された装置を構成するために有用であると証明してよい。多様なこれらのシステムのための構造は、以下に記載した記述から明らかになるだろう。更に、本発明の実施形態は、いかなる特定のプログラム言語をも参照しては記述されていない。様々な種類のプログラム言語が本明細書で記述する発明の実施形態の教示を実行するために用いられてもよいことが理解されるであろう。

機械可読な記録媒体は、機械（例えば、コンピュータ）で読み込み可能なフォームの情報を格納あるいは転送する、いかなる仕組みを含む。例えば、機械読み込み可能な記録媒体は、リードオンリーメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記録媒体、光記録媒体、フラッシュメモリディスク、電気的、光学的、音響的、あるいは伝播する信号の他の形態（例えば、搬送波、赤外信号、デジタル信号等）を含む。

図１は、一実施形態で用いられてよい典型的なコンピュータのブロック図である。例えば、図１に示す典型的なシステム１００は、図５から８に示したプロセスを実行してよい。典型的なシステム１００は、インテルペンティアム（登録商標）４ハイパースレッディングシステムのような、多重スレッドシステムであってよい。典型的なシステム１００は、同時実行マルチスレッディング（ＳＭＴ）、あるいはチップマルチ処理（ＣＭＰ）が有効なシステムであってよい。

ここで留意すべきは、図１はコンピュータシステムの様々な構成要素を図示する一方で、どのような特定のアーキテクチャ、又は、構成要素の相互接続の方法を表すことは意図していないことである。そのような詳細は本発明と密接に結びついていないからである。また、より少ない構成要素又はおそらくより多くの構成要素を有するネットワークコンピュータ、携帯型コンピュータ、携帯電話、そして他のデータ処理システムが、本発明と共に用いられてもよいことが理解されるであろう。図１に示すように、データ処理システムの形態であるコンピュータシステム１００は、マイクロプロセッサ１０３と、ＲＯＭ１０７、揮発性ＲＡＭ１０５、および非揮発性メモリ１０６とを接続するバス１０２を含む。インテル社からのペンティアムプロセッサ、又はモトローラ社からのパワーＰＣプロセッサであってよいマイクロプロセッサ１０３は、図１の例に示すようにキャッシュメモリ１０４に結合されている。バス１０２は、これらの様々な構成要素を互いに相互接続し、また、これらの構成要素１０３、１０７、１０５、および１０６を、マウス、キーボード、モデム、ネットワークインターフェース、プリンタ、および当該技術分野で周知の他のデバイスなどの入出力（Ｉ／Ｏ）デバイス１１０と同様にディスプレイコントローラおよびディスプレイデバイス１０８にも相互接続する。一般的に、入出力デバイス１１０は、入出力コントローラ１０９を介してシステムに接続される。揮発性ＲＡＭ１０５は、典型的には、リフレッシュ又はメモリ内のデータを保持するために継続的に電源供給を必要とする、動的ＲＡＭ（ＤＲＡＭ）として実行される。非揮発性メモリ１０６は、典型的には、磁気ディスク装置、磁気光学ディスク装置、光ディスク装置、あるいはＤＶＤ ＲＡＭまたはシステムから電源供給がなくなった後でもデータを保持する他の型のメモリシステムである。一般的に、非揮発性メモリはまた、必ずしも必要ではないが、ランダムアクセスメモリであってよい。図１では、非揮発性メモリが、データ処理システムの残りの構成要素に直接的に接続しているローカルデバイスである一方で、システムから離れている非揮発性メモリを、モデムやイーサネットインターフェースのようなネットワークインターフェースを介してデータ処理システムに接続されているネットワーク上の記憶装置として、本発明が利用してもよいことを理解されるであろう。バス１０２は、当該技術分野の当業者にとって周知の様々なブリッジ、コントローラ、および／又はアダプタを介してお互いに接続されている、一つ以上のバスを含んでいてよい。一実施形態においては、入出力コントローラ１０９は、ＵＳＢ周辺機器の制御のためのＵＳＢ（ユニバーサルシリアルバス）アダプタ、あるいは入出力デバイス１１０の中に含まれるＰＣＩデバイスの制御のためのＰＣＩコントローラを含んでいる。他の実施形態においては、入出力コントローラ１０９は、ファイアワイヤ（ＦｉｒｅＷｉｒｅ）装置としても知られる、ＩＥＥＥ１３９４装置の制御のためのＩＥＥＥ１３９４コントローラを含む。

一実施形態によれば、プロセッサ１０３は、非投機的スレッドとしても呼ばれる主要スレッド、および投機的スレッドとしても呼ばれるアプリケーションの一つ以上のヘルパースレッドを含む、多重スレッドを同時に扱うための論理プロセッサとも呼ばれる一つ以上の論理ハードウェアコンテキストを含んでいてよい。プロセッサ１０３は、インテル社からのマルチスレッディングプロセスが可能なペンティアム（登録商標）４やジオン（登録商標）プロセッサなどの、ハイパースレッディングプロセッサであってよい。アプリケーションの実行の間、主要スレッドと一つ以上のヘルパースレッドとは並行して実行される。ヘルパースレッドは、主要スレッドによって発生するメモリ遅延時間を減らすために、アドレスあるいはデータの投機的なプリフェッチングのようなある演算を実行する主要スレッドに関連して、いくらか独立してはいるが、投機的に実行される。一実施形態によれば、ヘルパースレッドのコード（例えば、ソースコードおよびバイナリ実行コード）は、プロセッサ１０３のようなプロセッサによって実行されるオペレーティングシステム（ＯＳ）によって揮発性ＲＡＭ１０５のようなメモリ中にロードされて実行される、インテル社から入手可能なオートヘルパーコンパイラのようなコンパイラによって生成される。

典型的なシステム１００の中で稼動しているオペレーティングシステムは、マイクロソフト社からのウィンドウズ（登録商標）、または、アップルコンピュータ社からのマックＯＳであってよい。他の例では、オペレーティングシステムは、リナックス、または、ユニックスであってもよい。組み込みの実時間オペレーティングシステムのような、他のオペレーティングシステムを利用してもよい。

一般に知られているハイパースレッディングプロセッサは、典型的には、二つのハードウェアコンテキスト、又は、論理プロセッサを備える。シングルスレッドアプリケーションの性能を向上させるために、ハイパースレッディング技術は、主要スレッドのためにプリフェッチングを実行する、その二番目のコンテキストを利用できる。分離したコンテキストを有することで、ソフトウェアによるプリフェッチングとは異なり、主要スレッドの制御フローから分離されるヘルパースレッドの実行を可能とする。長いレンジのプリフェッチの実行のために主要スレッドをはるか先まで実行することにより、ヘルパースレッドは早期にプリフェッチの契機を与え、主要スレッドによって経験されたキャッシュミスペナルティを、排除あるいは減少させる。

オートヘルパーによって、コンパイラは自動的にハイパースレッディング装置用のプリフェッチングヘルパースレッドを生成できる。ヘルパースレッドは、マルチスレッディングの遅延時間隠しの利益を、順次仕事量にもたらすことを目的とする。従来の並行コンパイラによって生成されたスレッドとは異なり、ヘルパースレッドは、ヘルパースレッドからの計算結果を再使用しない主要スレッドだけをプリフェッチする。

一実施形態によれば、ヘルパースレッドはプログラムの正確性に影響を与えず、もっぱら性能の向上にだけ使用される一方で、プログラムの正確性は、未だ主要スレッドの実行によって保たれている。この特性は、ヘルパースレッドを生成させることにおける、より積極的な形式の最適化の使用を可能とする。例えば、主要スレッドがヘルプを必要としないときは、従来のスループットスレッディングパラダイムでは不可能であった所定の最適化が実行されてよい。一実施形態によれば、仮に所定の時間の間にヘルパーが必要でないことが予測できる場合には、ヘルパーは終了してよく、主要スレッドに対するヘルパーに関連した全ての資源を解放してもよい。他の実施例によれば、仮にヘルパーがすぐに必要とされ得ることが予測できる場合には、ヘルパーはハイパースレッディングハードウェア上のいくらかの資源をまだ消費する、ポーズモードとなってよい。急激なバックオフ（停止を介して）が、仮にヘルパーが非常に長い間（例えば、プログラマブルタイムアウトを超える期間）ポーズモード状態でいるときに呼び出されてもよい。他の実施形態においては、仮にコンパイラがヘルパースレッドが必要とされるときを予測できない場合に、ヘルパーはスヌーズモードになってよく、主要スレッドのためにプロセッサ資源の支配を断念してもよい。

更に、一実施形態によれば、ヘルパースレッドが主要プログラムの動作に寄与しないので、パフォーマンスの監視およびオンザフライでの調整が、ヘルパースレッディングパラダイム下で可能とされる。主要スレッドがヘルパーを必要とする場合には、主要スレッドを起動させてもよい。例えば、ランナウェイ（ｒｕｎ−ａｗａｙ）ヘルパーまたはランビハインド（ｒｕｎ−ｂｅｈｉｎｄ）スレッドに関して、上述した一つのプロセスは、ランナウェイヘルパースレッドを調整するために呼び出されてよい。

図２は、開示された技術によって実行可能なコンピューティングシステム２００の一実施例を示すブロック図である。一実施形態においては、コンピューティングシステム２００は、プロセッサ２０４およびメモリ２０２を含む。メモリ２０２はプロセッサ２０４の可動を制御するための命令２１０およびデータ２１２を格納してよい。プロセッサ２０４は、実行コア２３０に命令情報を供給するフロントエンド２２１を含んでいてよい。フロントエンド２２１は、プログラム命令でプロセッサコア２０４へ命令情報を供給してもよい。

少なくとも一つの実施形態によれば、フロントエンド２２１は、複数のスレッドコンテキストのそれぞれのための、論理的に独立しているシーケンサ２２０を含むフェッチ／デコードユニット２２２を含んでいてよい。論理的に独立しているシーケンサ２２０は、投機的スレッドが「投機的」であるために命令情報をマークする、マーキングロジック２８０を含んでいてよい。当業者であれば、多重スレッド環境の多重プロセッサで実行される実施形態にとって、フェッチ／デコードユニット２２２内に、唯一つのシーケンサ２２２が含まれていてもよいことを理解するであろう。本明細書で使用するように、「命令情報」という用語は実行コア２３０によって理解され実行されることができる、命令を示すものを意味する。命令情報はキャッシュ２２５に格納されてよい。キャッシュ２２５は、実行命令キャッシュあるいは実行トレースキャッシュとして実行されてよい。

実効命令キャッシュを利用する実施例においては、「命令情報」は命令キャッシュからフェッチされた命令及びデコードされた命令を含んでいる。トレースキャッシュを利用する実施例においては、用語「命令情報」はデコードされたマイクロオペレーションを含む。実効命令キャッシュ及びトレースキャッシュの両方とも利用しない実施例においては、「命令情報」は、Ｉキャッシュ２４４のような命令キャッシュに格納されていてよい命令のｒａｗ型バイトをも含む。

図３は、一実施形態における、一つ以上のヘルパースレッドを生成するコンパイラを含む典型的なシステムを示すブロック図である。図３を参照すると、典型的な処理システム３００は、メモリシステム３０２及びプロセッサ３０４を含む。メモリシステム３０２は、プロセッサ３０４の稼動を制御するための命令３１０及びデータ３１２を格納してよい。例えば、命令３１０は、実行時に、プロセッサ３０４にメモリシステム３０２に常駐しているプログラムのコンパイルをさせるコンパイラプログラム３０８を含んでいてよい。メモリ３０２はコンパイルされるプログラム、プログラムの中間形態、およびコンパイルされたプログラムの結果を保持する。少なくとも一つの実施形態においては、コンパイラプログラム３０８は、主要なスレッドに対しての一つ以上のヘルパースレッドのためのコードを生成する命令を含む。

メモリシステム３０２は、メモリの一般的な表現を意味しており、ハードディスク装置、ＣＤ−ＲＯＭ、ランダムアクセスメモリ（ＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、および関連する回路のような、様々な形態のメモリを含んでよい。

メモリシステム３０２は、命令３１０および／またはプロセッサ３０４によって実行されてよいデータ信号によって表されるデータ３１２を格納してよい。命令３１０および／またはデータ３１２は、本明細書で述べる技術のいずれか又はすべてを実行するためのコードを含んでよい。

具体的には、コンパイラ３０８は、プロセッサ３０４によって実行されたときに、主要スレッドの一つ以上の不良ロード領域を特定する、不良ロード識別子を含んでよい。コンパイラ３０８は、プロセッサ３０４によって実行されたときに、ヘルパースレッドのために一つ以上の並列化分析を実行する、並列アナライザ３２４も含んでよい。また、コンパイラ３０８は、投機的な事前演算を実行するためにヘルパースレッドによって実行される一つ以上のスライスを特定するスライサ３２２を含んでよい。コンパイラ３０８は、更に、プロセッサ３０４によって実行されたときに、ヘルパースレッドのためにコード（例えば、ソースおよび実行コード）を発生する、コードジェネレータ３２８を含んでよい。

一実施形態において、図４Ｂに示したように、ＳＭＴ装置においてヘルパースレッドを実行することは、非対称のマルチスレッディングの形態となる。図４Ａに示したように、従来のプログラミングモデルは対称的なマルチスレッディングを提供する。その一方、図４Ｂに示したヘルパースレッド４５１から４５４のようなヘルパースレッドは、ユーザレベルのスレッド（ファイバー）として、軽いスレッドの起動とスイッチングで実行する。更に、対称的なマルチスレッディングは、図４Ａに示したスレッド４０１から４０４のように、対称的なスレッドの全体にわたって、よく同調されたデータ分解を必要とする。一実施形態において、ヘルパースレッドモデルでは、主要スレッドは、データ分解オーバヘッドを流入させることなしに、全データセット上で動作する順次コードを走らせる。データを分解せずに、コンパイラは代わりに適宜主要スレッドのデータのためにプリフェッチする多重ヘルパーを供給することに集中する。

図５は、一実施形態に係るヘルパースレッドを実行する典型的なプロセスのフロー図を示す。典型的なプロセス５００は、ハードウェア（回路、専用ロジック等）、ソフトウェア（一般的な目的のコンピュータシステム上や専用装置上で走らされるようなソフトウェア）、または両者の組み合わせを構成するプロセシングロジックによって実行されてよい。一実施形態においては、典型的なプロセス５００は、多重スレッドシステムのアプリケーションの主要スレッドを実行すること、および主要スレッドの編集中に生成される一つ以上のヘルパースレッドのコード、一つ以上の不良ロードを有する主要スレッドが領域に入った場合に、主要スレッドのための一つ以上の演算を実行する主要スレッドから一つ以上のヘルパースレッドを発生することを含む。

図５を参照すると、ブロック５０１において、プロセシングロジックは、一つ以上のヘルパースレッドによって使用されてもよい論理スレッドコンテキストのリストを保持する、内部スレッドプールを生成する。ブロック５０２において、新しいスレッドチームが、主要スレッドが、コンパイラによって特定されてよい不良ロード領域（例えば、事前演算領域）に入る前に生成されてよい。一実施例において、新しいスレッドチームは、初期状態においては呼出スレッド（ｃａｌｌｉｎｇ ｔｈｒｅａｄ）だけを含む。一実施例によれば、コンパイラは、一つ以上のヘルパースレッドを可動させる領域に主要スレッドが入る前に、開始ヘルパーステートメントのようなステートメントを挿入してよい。ブロック５０３では、主要スレッドが領域に入った場合に、主要スレッドは、（ヘルパー呼び出し命令のような関数呼び出しを介して）、主要スレッドのためのアドレスおよびデータをプリフェッチするような一つ以上の事前演算を実行するためのスレッドプールからの資源を使用して生成される、一つ以上のヘルパースレッドを発生する。一実施形態によれば、仮に発生したヘルパースレッドを実行するための論理プロセッサが利用可能でない場合には、ヘルパースレッドは、生成されて、続いて起こる実行のスレッドチームのための実行キューに置かれてよい。一実施形態では、実行キューはタイムアウトと関連付けられてよい。ヘルパーの呼出要求は、プリフェッチがもはや時宜にかなっていないと仮定して、タイムアウト期間が終了した後に単に脱落する（例えば、終了する）。これは従来の、各々のタスクが実行されることが要求される並列プログラミング用のタスクキューモデルとは異なるものである。ブロック５０４では、主要スレッドの領域内のコードの少なくとも一部が一つ以上のヘルパースレッドによって供給されたデータ（例えば、プリフェッチあるいは事前演算された）の一部を使用して実行される。一実施形態によれば、ヘルパースレッドによって計算された結果は、主要スレッド内に統合されない。ヘルパースレッドの利点は、その演算結果を再使用できる点にあるのではなく、プリフェッチングの副次的効果にある。これはコンパイラが、ヘルパースレッドのためのコード生成を積極的に最適化することを可能とする。主要スレッドは正確性の問題を扱い、一方ヘルパースレッドはプログラムの性能に照準を合わせる。これはまた、ヘルパースレッドが、適切と判断したときにはいつでも要求を落とすことのできる、ヘルパー呼び出しのようなステートメント呼び出しを可能とする。最終的には、プリフェッチ命令のような不良のない命令が、ヘルパースレッド内で例外が信号として検出された場合に、主要スレッドとの断絶を避けるために使用されてよい。

ブロック５０５では、主要スレッドがまさに不良ロード領域、および論理スレッドコンテキストのような、解放されてスレッドプールに戻される終了したヘルパースレッドに関連付けられる資源から出ようとしているときに、主要スレッドと関連付けられた一つ以上のヘルパースレッドが終了する（ヘルパー終了命令のような、関数呼び出しを介して）。これは、将来の要求に対して、スレッドプールからの論理スレッドコンテキストを即座にリサイクルすることを可能とする。当業者に明らかな他の動作も含んでよい。

ハイパースレッディング技術は、一つ以上のヘルパースレッドの実行をサポートすることによく適している。一実施形態によれば、各プロセッササイクルにおいて、いずれの論理プロセッサからの命令も、分担されている実行資源上で同時に実行され、スケジュールされ得る。これは、ヘルパースレッドにタイムリーなプリフェッチの発行を可能とする。更に、内蔵キャッシュの階層の全体が、キャッシュ階層の全てのレベルでの主要スレッドのために効果的にプリフェッチすることはヘルパースレッドに役立つ、論理プロセッサ間で分担される。その上、物理実行資源は論理プロセッサ間で分担されているものの、アーキテクチャ状態は、ハイパースレッディングプロセッサ内で再現される。ヘルパースレッドの実行は、主要スレッドを実行している論理プロセッサのアーキテクチャ状態を変えるものではない。

しかしながら、ハイパースレッディング技術が装置上で実行可能であるものの、ヘルパースレッドは、メモリに書き込むことによって主要スレッドの実行にまだ影響を与え得る。ヘルパースレッドはメモリを主要スレッドと共有しているため、主要スレッドのデータ構造に書き込まないことをヘルパースレッドの実行は保証されるべきである。一実施形態においては、コンパイラ（例えば、オートヘルパー）は、主要スレッドとヘルパースレッドとの間のメモリ保護を与える。コンパイラは、蓄積を、ヘルパースレッドの非局所的変数に移転する。

図６は、一実施形態に係るコンパイラの典型的なアーキテクチャを示すブロック図である。一実施形態では、典型的なアーキテクチャ６００は、とりわけ、フロントエンドモジュール６０１、プロファイラ６０２、内部手続分析および最適化モジュール６０３、コンパイラ６０４、グローバルスカラ最適化モジュール６０５、およびバックエンドモジュール６０６を含む。一実施形態では、フロントエンドモジュール６０１は、Ｃ／Ｃ++やフォートランのような、様々なプログラム言語によって記述されたソースコードのために、インテル社によるＩＬ０表現のような共通の内部表現を供給する。結果として、オートヘルパー６０４のようなコンパイラは、ソース言語および目標プラットフォームと関わりなく適用される。プロファイラ６０２は、表現の特徴を調査するためにプロファイリングランを実行する。内部手続き分析モジュール６０３は、プロシージャコール境界にわたって最適化の機会をさらしてよい。その後、コンパイラ６０４（例えば、オートヘルパー）は、一つ以上のヘルパースレッドのためのコードを生成するために実行される。グローバルスカラ最適化モジュール６０５は、部分的な冗長除去を使用して、評価される多数の表現を最小化することに適用する。最終的には、バックエンドモジュール６０６は、インテル社からのＩＡ−３２、あるいはアイテニアムプラットフォームのような、様々なプラットフォームのヘルパースレッドのための、バイナリコードを生成する。当業者にとって自明な他の構成要素を含んでいてもよい。従来のアプローチとは異なり、オートヘルパー（例えば、コンパイラ）は、ツールをより簡単に使えるように、プロファイル計測パスを除去する。

一実施形態によれば、ハイパースレッディング技術が可能であるインテル社のＶＴｕｎｅ（登録商標）Ｐｅｒｆｏｒｍａｎｃｅ Ａｎａｌｙｚｅｒなどによって生成された、プロファイリング結果からの出力をコンパイラは直接分析できる。ポスト−パス ツールの代わりに、ミドル−エンド パスであるので、コンパイラは、配列依存分析およびグローバルスカラ最適化などのような、いくつかの製品品質分析を利用できる。これらの分析は、コンパイラ後に呼び出され、ヘルパースレッドのコード上で積極的な最適化を実行する。

一実施形態によれば、コンパイラは、ロードによってアクセスされた高い頻度でキャッシュに失敗した不良ロードとも呼ばれるアドレスを、事前演算しプリフェッチする、一つ以上のヘルパースレッドを生成する。コンパイラは、また、一つ以上のヘルパースレッドを発生する、主要スレッド中に一つ以上のトリガを生成する。コンパイラはトリガを、ヘルパー機能コール呼出（ｉｎｖｏｋｅ＿ｈｅｌｐｅｒ ｆｕｎｃｔｉｏｎ ｃａｌｌ）などの機能呼出として使用する。一度トリガーが到達すると、ロードが主要スレッドの命令ストリーム中に後で出現することが予測されるので、投機的に実行されるヘルパースレッドは、主要スレッド中のキャッシュミスの数を減少させることができる。

図７は、一実施形態に係るオートヘルパーのような、コンパイラによって実行される典型的なプロセスを示したフロー図である。典型的なプロセス７００は、ハードウェア（回路、専用ロジック等）、ソフトウエア（一般的な目的のコンピュータシステム上や専用装置上で走らされるようなソフトウェア）、または両者の組み合わせを構成するプロセシングロジックによって実行されてよい。一実施形態において、典型的なプロセス７００は、詳細は以下で述べるように、不良ロードの使用を特定するために、例えばインテル社のＶＴｕｎｅツールで、ブロック７０１で開始し、ヘルパースレッドのための並行分析を実行し（ブロック７２０）、ヘルパースレッドのためのコードを生成し（ブロック７０３）、そして、各ヘルパースレッドおよび主要スレッドにハードウェアレジスタやメモリのような資源を割り当てる（ブロック７０４）。

一実施形態によれば、コンパイラは、一つ以上のランタイムプロファイルを使用するアプリケーションソースコード中のほとんどの不良ロードを特定する。従来のコンパイラは、二つの段階でプロファイルを集める。すなわち、プロファイル計測およびプロファイル生成である。しかしながら、キャッシュミスは、コンパイラにさらされているアーキテクチャの特徴ではないために、プロファイル計測パスは、不良ロードを特定するコンパイラのためのキャッシュミスの計測を許可しない。各キャッシュ階層のためのプロファイルは、インテル社のＶＴｕｎｅ（登録商標） Ａｎａｌｙｚｅｒのような、ユーティリティを介して収集される。一実施形態では、アプリケーションは、コンパイラに優先して離れたプロファイリング実行中のデバッグ情報と共に実行されてよい。プロファイリング実行中にキャッシュミスはサンプリングされ、ハードウェアカウンタがアプリケーション中の各静的ロードのために蓄積される。コンパイラはスレッドベースのプリフェッチングの候補を特定する。特定の実施形態では、ＶＴｕｎｅ（登録商標）が各ロード要素ごとのキャッシュの振る舞いを集約する。プロファイリング実行のためのバイナリがデバック情報（例えば、デバック記号）と共にコンパイルされるので、ソースライン番号とステートメントにプロファイルを相互に関連付けて戻させることが可能である。予め定められた閾値以上の原因となる所定のロードは、不良ロードとして特定されてよい。ある実施形態においては、キャッシュミスの９０％の原因となるトップロードを不良ロードとして表される。不良ロード命令を特定することに加えて、コンパイラは、正確に不良ロードのアドレスを計算するヘルパースレッドを生成する。一実施形態において、ヘルパースレッドの分離したコードが生成される。主要スレッドとヘルパースレッドのコードとの分離は、ヘルパースレッドのコードの変換が、主要スレッドに影響することを妨げる。一実施形態においては、コンパイラは、従来のアウトライニングの代わりに、インテル製品のコンパイラの中の多重エントリスレッディングを使用して、ヘルパースレッド用に分離したコードを生成する。更に、一実施形態においては、コンパイラは、事前演算領域として表わされるコンパイラ選択コード領域の精度において、多重エントリスレッディングを実行する。この領域は、不良ロードのセットを包含し、そして、理論的な事前演算の適用範囲を定義する。一実施形態では、ループは通常はプログラム実行の中でホットスポットであるため、実行は通常はループ領域を目標とし、そして、不良ロードは、通常はループ中で複数回実行されたロードである。

図８は、一実施形態に係る並列化分析の典型的なプロセスを示すフロー図である。典型的なプロセス８００は、ハードウェア（回路、専用ロジック等）、ソフトウエア（一般的な目的のコンピュータシステム上や専用装置上で走らされるようなソフトウェア）、または両者の組み合わせを構成するプロセシングロジックによって実行されてよい。図８を参照すると、ブロック８０１で、プロセシングロジックは、データおよび主要スレッドの制御の従属関係の双方を取り入れるディペンデンスグラフを構築する。一実施形態によれば、無関係のコードをフィルターにかけて除去し、ヘルパースレッドのコードサイズを減少させるために、コンパイラは、最初にデータおよびコントロールディペンデンスの双方を取り入れるグラフを構築する。フィルタリングの有効性および正当性は、コンパイラのメモリ参照を正確に明確にできる能力によっている。結果として、コンパイラ中のメモリ明確化モジュールは、動的にオブジェクトに割り当てられたポインタを明確にするために呼び出される。ポインタはグローバル変数またはファンクションパラメータであってよいので、仮にコンパイラが全プログラムモードでコンパイルする場合に、コンパイラによって実行される分析点は内部手続的である。一実施形態では、もし全ての配列のアクセスが限界評価の場合に、配列中の各要素がディペンデンスグラフの構築中に明確となるように、ディペンデンスグラフをより正確に構築するために配列ディペンデンステストのシリーズが実行されてよい。別の方法では、近似を用いる。更に、構造中の各フィールドは明確にされてよい。図８を再び参照すると、ブロック８０２では、プロセシングロジックが、ディペンデンスグラフを使用して主要スレッド上でスライシングオペレーション（ｓｌｉｃｉｎｇ ｏｐｅｒａｔｉｏｎ）を実行する。一実施形態において、スライシングの間において、コンパイラは、不良ロードのロードアドレスを、中間スライシング結果を特定するスライス基準として最初に特定する。ディペンデンスグラフを構築した後では、コンパイラは、特定されたスライス基準のプログラムスライスを計算する。スライス基準のプログラムスライスは、一つ以上のヘルパースレッドによって実行されるメモリプリフェッチのためのアドレスの計算に寄与する命令セットとして特定される。スライシングは、アドレスの計算に関連する命令だけにコードを減らすことができるので、主要スレッドに先立って、よりすばやくヘルパースレッドを走らせることが可能となる。コンパイラは、ヘルパースレッドのコードにスライスの命令をコピーする必要があるだけである。

一実施形態によれば、コンパイラ中のスライシングは、過渡的に後方にディペンデンスエッジ（ｄｅｐｅｎｄｅｎｃｅ ｅｄｇｅｓ）を横断することによって不良ロードのアドレスを生成する命令の最小のつながりを抽出する。スライス結果のディペンデンスグラフ上のリーフノードは、これ以上それらのリーフノードによって命令が決定されないために、プリフェッチ命令に変換され得る。インテル社から入手可能なペンティアム（登録商標）４のようなプロセッサによって実行されるそれらのプリフェッチ命令は、非ブロッキングおよび非フォールティングの双方である。メモリ階層中の異なるキャッシュレベルの中にデータを持ち込んで、異なるプリフェッチ命令は存続する。

一実施形態によれば、スライシング動作は、与えられたコード領域に関して実行されてよい。与えられた領域のディペンデンスグラフ上の横断（ｔｒａｖｅｒｓａｌ）は、その領域の外にコードが到達した場合には終了しなければならない。それゆえに、スライシングは、グラフ横断が領域の外まで補い、それから領域の内側に戻るので、横断後の代わりに横断中に終了されなければならない。単純に横断後の領域に応じてスライスを集めると、正確性を失いかねない。

他の実施例によれば、コンパイラは各不良ロード命令を一つずつスライスする。ヘルパースレッド中のコードの重複を最小化し、スレッドの起動および同期化のオーバーヘッドを減少させるために、コンパイラは、スライスが同一の事前演算領域にある場合に、スライスを一つのヘルパースレッドにマージする。

再び図８を参照すると、ブロック８０３において、プロセシングロジックは、多数のプリフェッチをオーバーラップさせるスレッドにわたってスケジューリングを実行する。一実施形態においては、ハイパースレッディングプロセッサは、大きなスケジューリングウィンドウで不調な実行をサポートするので、プロセッサは、ペンディングキャッシュミス上で待っている場合に、現在実行されている命令を越えて独立の命令を探索できる。この不調な実行の側面は、インオーダ（ｉｎ−ｏｒｄｅｒ）プロセッサにわたって相当のパフォーマンスゲインをもたらし、投機的な事前演算のチェーンの必要性を減少させることができる。更に、コンパイラは、ハイパースレッディングプロセッサのための基本的な投機的事前演算を選択する。すなわち、ただ一つのヘルパースレッドが、一度にスレッドの発生およびコミュニケーションのオーバーヘッドを記録するために、スケジュールされる。基本的な投機的事前演算を使用することの他の利点は、連鎖する投機的事前演算と同じぐらい速く、ハイパースレッディングプロセッサ上のメモリシステムを満たさないことである。

不調なプロセッサが実行するための独立命令を探す場合には、それらの命令は非常に多くのロード要求を生成してメモリシステムを満たすことができる。ヘルパースレッドがプリフェッチング要求を発行した場合には、多くの目立ったミスは、急速にミスバッファを満たし、結果としてプロセッサを止めてしまう。それゆえに、コンパイラは、ヘルパースレッドを発生させることに賢明さが要求される。最終的には、タイムリーなプリフェッチングを確実にするために、コンパイラは、各論理プロセッサごとのシングルヘルパースレッドおよび主要スレッドを特定する。

図８を再び参照すると、ブロック８０４では、プロセシングロジックはスレッドのためにコミュニケーションスキームを選択する。一実施形態では、コンパイラは、与えられたどのようなスライス、あるいはどのようなプログラムのサブセットのために、ライブネス（ｌｉｖｅ−ｎｅｓｓ）情報を演算するモジュールを供給する。ライブネス情報はコミュニケーションコスト上の見積もりを提供する。情報は、コミュニケーションと演算との間のよいトレードオフ関係を提供するために、事前演算領域を選択するために用いられる。ライブネス情報は、トリガ、あるいは後方のスライシング末端のポイントの発見の補助をしてもよい。典型的なハイパースレッディングプロセッサはプロセッササイクルごとに３つのマイクロオプスを発行し、いくらかのハード分割されたリソースを使用するので、特に、仮に主要スレッドが、既に、サイクルごとの実行に３つのマイクロオプスを発行している場合に、コンパイラは、ヘルパースレッドに主要スレッドの実行を遅延させないほど賢明でなければならない。ループは不良ロードを取り込んでネストするために、コンパイラは、再計算と投機的な事前演算を実行するためのループレベルを選ぶコミュニケーションとの間のトレードオフを作成する。

一実施形態によれば、最深部から始まる各ループレベルのために、コンパイラは、コミュニケーションベースのスキームと演算ベースのスキームの一つを選択する。一実施形態によれば、コミュニケーションベースのスキームは、ライブインバリューと、主要スレッドからヘルパースレッドに互いに繰り返して通信するので、ヘルパースレッドは再計算ライブインバリューを、必要としないこととなる。ほとんどの不良ロードを包含する内部ループが存在し、内部ループのためのスライシングがヘルパースレッドのサイズを著しく減少させた場合には、コンパイラは当該スキームを選択してよい。しかしながら、当該スキームは、内部ループレベルのコミュニケーションコストが非常に大きい場合には、無効とされてよい。コンパイラは、ライブインバリューが早期に計算されて、ライブインの数が小さい場合には、コミュニケーションコストのより小さな見積もりを与えてよい。コミュニケーションベースのスキームは、ランタイムにおいて主要スレッドとそのヘルパースレッドとの間に、複数のコミュニケーションポイントを生成してよい。

ヘルパースレッド内のスライスを再計算することによって、ただ一つのコミュニケーションポイントに依存すると、非常に多くのスレッド間のリソースコンテンションが作成され得るので、コミュニケーションベースのスキームは、ハイパースレッディングプロセッサにとって重要である。当該スキームは、繰り返しのためのライブインバリューを演算し終えた後に、主要スレッドが次の反復を開始するので、ドゥーアクロースループ（ｄｏ−ａｃｒｏｓｓ ｌｏｏｐ）の構築と類似している。スキームは、より少ない演算のためのコミュニケーションを交換する。

一実施形態によれば、演算ベースのスキームは、初期状態でライブインバリューを通過する二つのスレッドの間の唯一つのコミュニケーションポイントを仮定する。それ以降、ヘルパースレッドは、正確なプリフェッチアドレスを生成するために必要とする全ての計算をすることを必要とする。コンパイラは、内部ループがない場合、あるいは、当該ループレベルのためのスライシングがヘルパースレッドのサイズを著しく増加させない場合に、当該スキームを選択してよい。演算ベースのスキームは、一度シングルコミュニケーションポイントが到達した場合に、ヘルパースレッドに、実行においてより独立しているヘルパースレッドを与える。

一実施形態によれば、投機的な事前演算のためのループレベルを選択するために、コンパイラは、コミュニケーションベースのスキームから利得を得る、最外部のループを選択する。それゆえに、上記で述べたスキーム選択アルゴリズムは、一度コミュニケーションベースのスキームとのループを発見したときは、終了できる。コンパイラがコミュニケーションベースのスキームとのループを何ら発見しなかった場合には、最外部のループが投機的な事前演算のための領域として対象とされてよい。コンパイラが事前演算領域およびそれらのコミュニケーションスキームを選択した後は、主要スレッドとヘルパースレッドとの間のコミュニケーションを最小にする一方で、主要スレッド中のよいトリガーポイントを設置することは、タイムリーなプリフェッチを確実なものとする。ライブネス情報は後方のスライシング末端におけるポイントである、トリガを設置することに役立つ。事前演算領域を超えたスライシングは、ライブインの数が増加した場合に終了する。

再び図８を参照すると、ブロック８０５では、プロセシングロジックは、実行中に互いに同期化するスレッドのための同期化期間を決定する。一実施形態によれば、同期化期間は、ヘルパースレッドと主要スレッド間の距離を表現するために使用される。典型的には、ヘルパースレッドは、同期化期間のユニット内のその事前演算の全てで実行する。これは、コミュニケーションを最小にして、ランナウェイ（ｒｕｎ−ａｗａｙ）ヘルパーを生成する可能性を制限する。コンパイラは同期化期間のバリューを計算し、それに応じて同期化コードを生成するので、アウトスタンディングスライスカウンタ（Ｏｕｔｓｔａｎｄｉｎｇ Ｓｌｉｃｅ Ｃｏｕｎｔｅｒ）のようなハードウエアのサポートはもはや不要である。

同期化期間が非常に大きい場合には、ヘルパースレッドによって引き起こされたプリフェッチは、主要スレッドによって用いられるために一時的に重要なデータに置き換わるだけではなく、潜在的に主要スレッドによって未だ用いられていない、以前のプリフェッチデータへの置き換わりを引き起こす。他方では、同期化期間が非常に小さい場合には、プリフェッチはとても遅すぎて用いることができない。一実施形態において、同期化期間のバリューを決定するために、コンパイラは最初に、スライスの長さと主要スレッド内のプログラムの長さとの差異を計算する。差異が小さい場合には、一の繰り返しでヘルパースレッドによって引き起こされた実行距離（ｒｕｎ−ａｈｅａｄ ｄｉｓｔａｎｃｅ）は必然的に小さい。複数の反復が、十分な実行距離を維持するためにヘルパースレッドによって必要とされてもよい。それゆえに、コンパイラは、差異が小さい場合には同期化期間を増加し、また逆の場合も同様である。その後に、コンパイラは、コード生成ステージの間に、主要スレッドのためにコードおよびヘルパースレッドを生成する。コード生成ステージの間に、コンパイラは、分析フェーズとコード生成フェーズとの間のインターフェースとしてスレッドグラフを構築する。各グラフのノードは、命令のシーケンス、またはコード領域を示す。ノード間の起動エッジは、ヘルパースレッドの連結の明確化に重要である、スレッド発生関係を示す。一実施形態によれば、スレッドグラフを有していると、ユーザがヘルパースレッドとライブインにコードを指定するために、コンパイラはプラグマ（ｐｒａｇｍａｓ）をソースプログラムに挿入するので、コード再利用が可能となる。プラグマベースのアプローチおよび自動的アプローチは療法共に、同一のグラフ抽象化概念を共有する。結果として、ヘルパースレッドコード生成モジュールが共有されてよい。

ヘルパースレッドコード生成は、ヘルパースレッドを生成するコンパイラ中で、マルチエントリスレッディング技術を利用する。従来とは対照的に、概要は周知であるが、コンパイラは、ヘルパースレッドのために分離した編集ユニット（あるいは、ルーチン）を生成しない。代わりに、コンパイラは、ヘルパースレッドコートにスレッドされたエントリーおよびスレッドされたリターンを生成する。コンパイラは、全ての新たに生成されたヘルパースレッドコードを、原形を保ち、あるいは独立のサブルーチンに分離することなしに、同一のユーザ定義のルーチンの中のインラインに保つ。この手法は、新たに生成されたヘルパースレッド上での最適化を実行する、より多くの機会を、後のコンパイラの最適化に提供する。ヘルパースレッドでのより少ない指示は、ハイパースレッドプロセッサにおけるより少ないリソースコンテンションを意味する。これは、待ち時間を隠すためにヘルパースレッドを用いることが、ハイパースレッドプロセッサがプロセッササイクル当たり３つのマイクロオプスを発行し、いくつかにハード分割したリソースを有するために特に重要である、従来の対称的なマルチスレッディングモデルよりも、より少ない命令とより少ないリソースコンテンションをもたらすことを示す。

一実施形態によれば、ヘルパースレッドのために生成されたコードは、部分死滅ストア除去（ＰＤＳＥ）、部分冗長性除去（ＰＲＥ）、およびその他のスカラー最適化のようなコンパイラ中の後のフェーズ上で、再整列および最適化されてよい。その意味で、ヘルパースレッドコードは、ヘルパースレッドによるリソースコンテンションを最小化するために最適化される必要がある。しかしながら、その様な更なる最適化は、コードをプリフェッチングすることも同様に除いてしまい得る。それゆえに、リーフ不良ロードは、コンパイラにおける揮発性代入文に変換されてもよい。スライスのディペンデンスグラフにおけるリーフノードは、ロードされた値に依存する、ヘルパースレッドのそれ以上の命令はないことを暗示する。そのため、揮発性代入文のあて先は、結果として生じるコードを早くするための表現で、レジスタテンプ（ｒｅｇｉｓｔｅｒ ｔｅｍｐ）に変更される。揮発性代入を用いることにより、コンパイラグローバル最適化の後のすべてが、不良ロードのために生成されたプリフェッチを取り除くことを妨げ得る。

一実施形態によれば、コンパイラは、ヘルパースレッドが、自動計算機構を用いて主要スレッドから先過ぎず、後過ぎないように実行することを確実にすることを目的とする。一実施形態によれば、Ｘ値が距離制御の実行に先立って予めセットされる。Ｘは、ユーザによって、あるいは、スライス（あるいはヘルパーコード）の長さおよび主要コードの長さのプログラム分析に基づいて、コンパイラスイッチを介して修正されることができる。一実施形態では、コンパイラは、主要スレッドのために初期値Ｘとしてｍｃ（Ｍカウンタ）を、およびヘルパースレッドのために初期値０としてｈｃ（Ｈカウンタ）を生成し、コンパイラは、主要およびヘルパーコードのシンクアップ（ｓｙｎｃ−ｕｐ）期間をカウントするカウンタＭおよびＨを生成する。４つのカウンタ（ｍｃ、Ｍ、ｈｃ、Ｈ）全てが自動カウントを実行するという考えである。ヘルパースレッドは主要スレッドに対する推論は有しない。ヘルパースレッドが主要スレッドのかなり先に実行している場合には、それは待ちを発行してよく、ヘルパースレッドが主要スレッドの後に実行している場合には、それはキャッチアップを実行してよい。

特定の実施形態において、各Ｘループ反復のために、主要スレッドは、ヘルパーが待たず、非フォールティングロード（ｎｏｎ＿ｆａｕｌｔｉｎｇ＿ｌｏａｄ）実行のために先に進むことのできることを確実にするためのポストを発行する。この点では、ヘルパースレッドが多くのシンクアップ期間で多数の非フォールティングロードを発行した後に主要スレッドを待っている場合には、ヘルパースレッドは、非フォールティングロードを実行するために起動してよい。他の特定の実施形態においては、各Ｘループ反復のために、ヘルパースレッドは、そのｈｃカウンタが主要スレッドのｍｃカウンタより大きいか、およびｈｃカウンタがヘルパースレッドのシンクアップ期間Ｈ＊Ｘより大きいかを調べて、そうであるならば、ヘルパーは待ちを発行してスリープ状態になってよい。これは、ヘルパースレッドが主要スレッドのはるか前に実行されることを妨げる。他の実施形態においては、他の多くのシンクアップ期間上の反復の前に、ヘルパースレッドは、そのｈｃカウンタが主要スレッドのｍｃカウンタよりも小さいか否かを調査する。そうであるならば、ヘルパースレッドは遅延して、カウンタｈｃと、Ｈと、全ての取得したプライベート（ｐｒｉｖａｔｅ）と、主要スレッドからのライブイン変数をアップデートすることにより、「キャッチアップおよび先へのジャンプ」をしなければならない。図９Ａから図９Ｃは、一実施形態における、アプリケーション、主要スレッド、およびヘルパースレッドの典型的な擬似コードを示す図である。図９Ａから図９Ｃを参照すると、コンパイラはアプリケーションのソースコード９０１をコンパイラして、前述した技術の少なくとも一つを使用する主要スレッド９０２およびヘルパースレッド９０３のためにコードを生成する。コード９０１から９０３はＣ／Ｃ＋＋に限定されないことが理解されるであろう。例えばフォートランやアセンブリ言語のような、他のプログラム言語を用いてもよい。

ヘルパースレッド用のコードが生成された後は、主要スレッドとヘルパースレッドの間、およびヘルパースレッド間のリソースコンフリクトがないことを確実にするために、コンパイラは、各ヘルパースレッドおよび主要スレッドにリソースを、静的または動的に更に割り当ててよい。レジスタコンテキストのようなハードウエアリソースは、コンパイラ中のヘルパースレッドのために管理されてよい。具体的には、レジスタセットが静的または動的に、主要スレッドとヘルパースレッドとの間、および複数のヘルパースレッドの間で分割されてよい。結果として、スレッドのメモリを介してのライブイン／ライブアウトレジスタのコピーが避けられ、コンパイラがリソースを使い果たした場合に、コンパイル時間で、または、ある主要レッドのイベントが起こるまれな場合に、ランタイムでスレッドが破棄される。

一実施形態によれば、図１２に示したリソースの表のように、コンパイラはボトムアップオーダでヘルパースレッドを「ウォークスルー（ｗａｌｋ ｔｈｒｏｕｇｈ）」してよく、データ構造でリソースの利用を伝える。主要スレッドであってもよい親ヘルパースレッドは、この情報を利用して、そのリソースが、スレッドリソースとオーバーラップしないことを確実にする。スレッドリソースが主要実行スレッドに不利益を与える場合には、例えば、主要スレッドをレジスタで溢れさせる／満たすことを促進することにより、コンパイラは既に生成されたスレッドを無効にできる。

図１０は、一実施形態に係るスレッドの典型的な構造を示すブロック図である。当該実施形態においては、典型的な構造１０００は、主要スレッド１００１（例えば、親スレッド）と、スレッド１００３がスレッド１００２（例えば、ヘルパースレッド１００２は、ヘルパースレッド１００３の親スレッドである）から生成されてよい一方で、主要スレッド１００１から生成されてよい、３つのヘルパースレッド（例えば、子スレッド）１００２から１００４とを含む。ヘルパースレッドは３つのヘルパースレッドに限られるものではなく、多少のヘルパースレッドが含まれていてもよいことは理解されるであろう。

ヘルパースレッドは、生成命令によって生成されてよく、スレッドの実行は、生成命令の後に再開されてもよい。複数のスレッドは、図５から図８に示した動作のような、スレッド生成フェーズの間にコンパイラによって生成される。一実施形態によれば、コンパイラは、３つの生成フェーズ中でスレッドを生成して、続くスレッドリソース割り当てフェーズでスレッドにリソースを割り当てる。動的にそして典型的に、ヘルパースレッドは、その親スレッドが停止した場合に生成される。典型的な構造１０００は、ページフォルトあるいはレベル３（Ｌ３）のキャッシュミスの間に起こり得る。

スレッドがインカミング（ｉｎｃｏｍｉｎｇ）レジスタ（あるいは、リソース一般）だけを親スレッドと共有できることは重要である。例えば、図１０を参照すると、主要スレッド１００１がレジスタを必要とした場合には、主要スレッド１００１は、ヘルパースレッド１００２を生成する前にレジスタＲ１０に値を書き込み、そして、ヘルパースレッド１００２が終了した後にレジスタＲ１０を使用する。ヘルパースレッド１００２もその子供（例えば、ヘルパースレッド１００３はヘルパースレッド１００２の子供たちだけであり、ヘルパースレッド１００２および１００４は主要スレッド１００１の子供である）のどちらもレジスタＲ１０に書き込むことはできない。さもなければ、それらは主要スレッド１００１の値を破棄し得る。これは、不正確なプログラム実行となり得る。このリソースコンフリクトを回避するために、一実施形態においては、コンパイラはリソースを静的または動的に割り当ててよい。

一実施形態によれば、コンパイラは、ヘルパースレッドおよびボトムアップオーダの主要スレッドにリソースを割り当てる。図１１は、一実施形態に係るスレッドのリソース割り当てのための典型的な擬似コードを示すブロック図である。典型的なアルゴリズム１１００によれば、ボトムアップオーダ（ブロック１１０１）のヘルパースレッドのために、全てのリソースを割り当てるのはコンパイラであり、その後、リソースコンフリクトを避けるためにヘルパースレッドによって用いられたリソースに基づいて、主要スレッド（ブロック１１０２）にリソースを割り当てる。

図示した目的は、スレッドに使用されるリソースは、ハードウエアレジスタであると仮定される。しかしながら、同様のコンセプトが、メモリや割り込みのような、当業者に自明な他のリソースに適用されてよい。図１０を参照すると、コンパイラは、スレッドチェーンのリードスレッドからボトムアップのウォーキングによって、レジスタを動的に分割する。この例においては、ヘルパースレッド１００３は、ヘルパースレッド１００２を含む最初のスレッドチェーンのリーフスレッドである。ヘルパースレッド１００４は、２番目のスレッドチェーンのリーフスレッドである。コンパイラは、図１２の典型的なリソーステーブル１２００と同様のリソーステーブルのような、データ構造中の各ヘルパースレッドのレジスタの割り当てを記録する。そして、親スレッドは、その子スレッドのリソース割り当てを読み込み、そして割り当てをし、そのリソーステーブルに記録する。

図１２は、一実施形態に係る典型的なリソースデータ構造を示すブロック図である。典型的なデータ構造１２００は、メモリ中に格納され、およびコンパイラによってアクセス可能なテーブルとして実行されてよい。他の例では、典型的なデータ構造１２００がデータベース中で実行されてよい。一実施形態においては、典型的なデータ構造１２００は、限定されるわけではないが、記述リソース１２０２、およびスレッドＩＤ１２０１を介して特定される各個別のスレッドによって使用されるライブインリソースを含む。他の構造が存在していてもよい。

図１０から図１２を参照すると、一実施形態によれば、最初に、ヘルパースレッド１００３（例えば、ボトムアップスキームにおいて最も下部の順にあるスレッド）のレジスタが割り当てられる。ライブインバリューはＶ５とＶ６であり、それらはそれぞれレジスタＲ２およびＲ３に割り当てられると仮定される。また、Ｖ７はレジスタＲ４を割り当てさせ、そして、Ｖ９はレジスタＲ５を割り当てさせる。ヘルパースレッド１００３のためのリソーステーブルは、図１２に示すように、ライブイン＝（（Ｖ５、Ｒ２）、（Ｖ６、Ｒ３））および記述されたレジスタ＝（Ｒ４、Ｒ５）を含む。ヘルパースレッド１００２中でコンパイラは、割り当ての間にＶ５をＲ２と、Ｖ６をＲ３と置き換え、そして、レジスタＲ４およびＲ５（ヘルパースレッド１００３に記述されている）を、生成命令においてライブ（ｌｉｖｅ）としてマークする。これは、ヘルパースレッド１００３の発生ポイントにわたってＲ４またはＲ５のレジスタ使用を妨げるので、ヘルパースレッド１００２とヘルパースレッド１００３との間のリソースコンフリクトを妨げる。ヘルパースレッド１００２については、ライブインバリューはＶ３およびＶ４であり、それぞれレジスタＲ６およびＲ７が割り当てられる。Ｖ８およびＶ２０がレジスタＲ８およびＲ９にそれぞれ割り当てられた場合に、ヘルパースレッド１００２のリソーステーブルは、図１２に示すように、ライブイン＝（（Ｖ３、Ｒ６）、（Ｖ４、Ｒ７））および記述されたレジスタ＝（Ｒ２、Ｒ３、Ｒ４、Ｒ５、Ｒ８、Ｒ９）を含む。記述されたレジスタは、ヘルパースレッド１００３（例えば、Ｒ２およびＲ３）のためのライブインレジスタ、ヘルパースレッド１００３（例えば、Ｒ４およびＲ５）内の記述されたレジスタ、およびヘルパースレッド１００２（例えば、Ｒ８およびＲ９）内の記述されたレジスタである。そして、コンパイラはヘルパースレッド１００４のためにレジスタを割り当てる。全てのヘルパースレッドにレジスタが割り当てられた場合には、主要スレッド１００１のためにレジスタを割り当てる。

更に、一実施形態によれば、コンパイラがレジスタを使い果たした場合には、チェーン内の一つ以上のヘルパースレッドを消去できる。これは例えば、ヘルパースレッドのチェーンが深すぎるため、あるいはシングルヘルパースレッドが非常に多くのレジスタを必要とするため、主要スレッドがレジスタを溢れさせる／満たすために、主要スレッドがレジスタを使い果たした場合に起こり得る。コンパイラは、所定の数の流出を許容するか、またはヘルパースレッドチェーンの全体か、またはスレッドチェーンのいくつかのスレッドを削除するために、経験則を当てはめることができる。ヘルパースレッドを消去する他の方法は、コンテキストスイッチ上で、ヘルパースレッドの実行によって記述されることができる親のライブレジスタが、ハードウエアによって自動的にセーブされることができるように、コンテキストのセーブ／回復の重みを明確に設定することである。このコンテキストスイッチは比較的高価ではあるものの、その様な場合は、潜在的にはめったに起こらないケースである。

更には、その様な細かいコンテキストスイッチは、ほとんどのＯＳ実行可能なスレッドスイッチ、または従来のハードウエアベースのフルコンテキストスレッドスイッチに用いられるフルコンテキストスイッチと比較すると、まだ多くの低いオーバヘッドのものである。

更に、ライブインレジスタにコンフリクトがある場合、例えば、ヘルパースレッド１００３がライブインレジスタ（例えば、ｍｏｖ ｖ５＝・・・）に上書きして、当該レジスタがまた、ヘルパースレッド１００３の発生の後で、ヘルパースレッド１００２内で使用される場合には、ｖ５（この例ではレジスタＲ２）に割り当てられたレジスタにリソースコンフリクトがあるであろう。この情報を扱うために、コンパイラは、利用可能な分析の使用をしてよく、ヘルパースレッド１００３の生成前にｍｏｖ ｖ５’＝ｖ５命令の挿入や、発生後にｖ５をｖ５’に置き換えるような補償コードを挿入してよい。

図１３は、一実施形態に係るスレッドにリソースを割り当てる典型的なプロセスを示したフロー図である。典型的なプロセス１３００は、ハードウェア（回路、専用ロジック等）、ソフトウェア（一般的な目的のコンピュータシステム上や専用装置上で走らされるようなソフトウェア）、または両者の組み合わせで構成されてよいプロセシングロジックによって実行されてよい。一実施形態では、典型的なプロセス１３００は、データ処理システム中の一つ以上のスレッド実行ファイルを有するコードの編集の間に、最も下部のオーダを有するカレントスレッドを選択すること、カレントスレッドから生成された一つ以上のスレッドに割り当てられたリソースを決定すること、および、カレントスレッドとその一つ以上の子スレッドとの間のリソースコンフリクトを避けるために、カレントスレッドに、カレントスレッドの一つ以上の子スレッドに割り当てられたリソースを考慮してリソースを割り当てることを含む。

図１３を参照すると、ブロック１３０１において、プロセシングロジックは、主要スレッドおよびそのヘルパースレッドを含む一つ以上のスレッドを特定して、カレントスレッドとして最も下部のオーダを有するスレッドを選択する。編集のスレッド生成フェーズ中に生成されたスレッドディペンデンシーグラフ（ｔｈｒｅａｄ ｄｅｐｅｎｄｅｎｃｙ ｇｒａｐｈ）を用いて、スレッドは特定されてよい。ブロック１３０２において、プロセシングロジックは、どのような子スレッドのリソース情報をも取り込む、カレントスレッドから生成されてよい。リソース情報は、図１２のリソーステーブル１２００のような子スレッドに対応するデータ構造から得られてよい。ブロック１３０３において、もはや利用可能なリソースがない場合には、プロセシングロジックは、一つ以上のスレッドをチェーンから消去してよく、反復して再スタートしてもよい（ブロック１３０９）。利用可能なリソースがまだある場合には、ブロック１３０４において、プロセシングロジックは、リソースコンフリクトを起こさずにその子スレッドによって使用されているリソースを考慮して、カレントスレッドにリソースを割り当てる。それゆえに、ブロック１３０５において、プロセシングロジックは、リソーステーブル１２００のような、リソーステーブルに関連付けられるカレントスレッドに割り当てられたリソースをアップデートする。上記のプロセスは、ヘルパースレッド（例えば、主要スレッドの子スレッド）が全く残らなくなるまで（ブロック１３０６および１３０８）継続する。最終的には、ブロック１３０７において、プロセシングロジックは、リソースコンフリクトを起こす原因とならない全てのヘルパースレッドのリソース情報に基づいて、リソースを主要スレッド（例えば、全てのヘルパースレッドの親スレッド）に割り当てる。他の動作を含んでいてもよい。

上述した技術は、次の設定と同様のシステムに基づいた様々なベンチマークツールに対して評価された。

様々なマナベンチマークツールは、以下の少なくとも一つを含む。

図１４Ａは、ｎｂｏｄｙ＿ｗａｌｋｅｒベンチマークユーティリティ上における、ヘルパースレッドによる性能の向上を示す表である。図１４Ｂは、同期化期間の与えられた値での、ｎｂｏｄｙ＿ｗａｌｋｅｒの速度向上結果を示す表である。図１４Ｃは、様々なベンチマークに関して、自動プロセスに対する手動プロセスを示す表である。図１４Ｄは、与えられた同期化期間におけるｎｂｏｄｙ＿ｗａｌｋｅｒを用いた手動プロセス上の自動化プロセスの向上を示す表である。

以上、マルチスレッディングのためのスレッド管理の方法および装置について説明した。以上の明細書においては、本発明はその典型的な実施形態を参照して記述した。添付した特許請求の範囲で説明する本発明の広い精神および範囲を逸脱せずに、様々な変更改造を加えうることは明らかである。従って、本明細書および図面は、限定的な意味というよりも例示的な意味として考えられるべきである。

一実施形態に係るマルチスレッド機能を有するコンピュータシステムを図示する。 他の実施形態に係るマルチスレッド機能を有するコンピュータシステムを図示する。 一実施形態に係るヘルパースレッドを生成することのできるコンパイラを有するコンピュータシステムを図示する。 図４Ａは、典型的な対称的マルチスレッドプロセスを図示する。図４Ｂは、一実施形態に係る非対称マルチスレッドプロセスを図示する。 一実施形態に係る一つ以上のヘルパースレッドを実行する典型的なプロセスを示すフロー図である。 一実施形態に係るマルチスレッドシステムの典型的なソフトウェアアーキテクチャを図示するブロック図である。 一実施形態に係るヘルパースレッドを生成するための典型的なプロセスを示すフロー図である。 一実施形態に係る並列化分析の典型的なプロセスを示すフロー図である。 図９Ａから９Ｃは、一実施形態に係るアプリケーション、メインスレッド、およびヘルパースレッド用の擬似的コードを示す。 一実施形態に係る典型的なスレッド設定を図示するブロック図である。 一実施形態に係るスレッドに資源を割り当てるための擬似的なコードを示すブロック図である。 一実施形態に係るスレッドのための資源情報を含む、典型的な資源データ構造を示すブロック図である。 一実施形態に係るスレッドに資源を割り当てる典型的なプロセスを示すフロー図である。 図１４Ａから１４Ｄは、複数の方法の実施形態を使用した様々なベンチマークテストの結果を示す。

Claims (20)

1. データ処理ユニット中の一つ以上の実行ファイルを有するコードの編集中に、最も下部の順を有するカレントスレッドを選択する選択段階と、
   前記カレントスレッドから生成された一つ以上の子スレッドに割り当てるリソースを決定する決定段階と、
   前記カレントスレッドと当該カレントスレッドの一つ以上の子スレッドとの間のリソースコンフリクトを避けるために、前記カレントスレッドの一つ以上の子スレッドに割り当てられたリソースに考慮して、前記カレントスレッドにリソースを割り当てる割り当て段階とを備える方法。
2. 前記リソースが、前記各々のスレッドによって使用される少なくとも一つのハードウェアレジスタおよびメモリを含む請求項１に記載の方法。
3. 前記一つ以上の子スレッドに割り当てられた前記リソースが、前記カレントスレッドによってアクセス可能なデータ構造中に記録される
   請求項１に記載の方法。
4. 前記カレントスレッドに割り当てられた前記リソースに関してのデータ構造中のリソース情報をアップデートする段階を更に備え、
   前記データ構造が前記カレントスレッドの親スレッドによってアクセス可能である請求項１に記載の方法。
5. 一つ以上の前記スレッドのそれぞれが実行されるまで、ボトムアップの順に、前記選択段階、前記決定段階、および前記割り当て段階を繰り返す段階を更に備える請求項１に記載の方法。
6. 前記一つ以上のスレッドのそれぞれが実行された後に、前記一つ以上のスレッドの親スレッドである主要スレッドにリソースを割り当てる段階を更に備え、
   前記主要スレッドの前記リソースが、前記一つ以上のスレッドに割り当てられたりソースを考慮して割り当てられる請求項５に記載の方法。
7. 前記カレントスレッドに前記リソースを割り当てる前記段階に優先して、前記データ処理システム内にリソースが残っているか否か決定する段階と、
   前記カレントスレッドの少なくとも一つの子スレッドを消去する段階と、
   前記少なくとも一つの消去された子スレッドに関連付けられる前記リソースを用いて前記カレントスレッドに前記リソースを割り当てる段階とを更に備える請求項１に記載の方法。
8. 装置に方法を実行させる実行コードを有する機械可読な媒体であって、前記方法が、
   データ処理ユニット中の一つ以上の実行ファイルを有するコードの編集中に、最も下部の順を有するカレントスレッドを選択する段階と、
   前記カレントスレッドから生成された一つ以上の子スレッドに割り当てるリソースを決定する段階と、
   前記カレントスレッドと当該カレントスレッドの一つ以上の子スレッドとの間のリソースコンフリクトを避けるために、前記カレントスレッドの一つ以上の子スレッドに割り当てられたリソースに考慮して、前記カレントスレッドにリソースを割り当てる段階とを備える機械可読な媒体。
9. 前記リソースが、前記各々のスレッドによって使用される少なくとも一つのハードウェアレジスタおよびメモリを含む請求項８に記載の機械可読な媒体。
10. 前記一つ以上の子スレッドに割り当てられた前記リソースが、前記カレントスレッドによってアクセス可能なデータ構造中に記録される請求項８に記載の機械可読な媒体。
11. 前記カレントスレッドに割り当てられた前記リソースに関してのデータ構造中のリソース情報をアップデートする段階を更に備え、前記データ構造が前記カレントスレッドの親スレッドによってアクセス可能である請求項１に記載の方法。
12. 前記方法が、
    一つ以上の前記スレッドのそれぞれが実行されるまで、ボトムアップの順に、前記選択段階、前記決定段階、および前記割り当て段階を繰り返す段階を更に備える請求項８に記載の機械可読な媒体。
13. 前記方法が、前記一つ以上のスレッドのそれぞれが実行された後に、前記一つ以上のスレッドの親スレッドである主要スレッドにリソースを割り当てる段階を更に備える請求項１２に記載の機械可読な媒体。
14. 前記方法が、
    前記カレントスレッドに前記リソースを割り当てる前記段階に優先して、前記データ処理システム内にリソースが残っているか否か決定する段階と、
    前記カレントスレッドの少なくとも一つの子スレッドを消去する段階と、
    前記少なくとも一つの消去された子スレッドに関連付けられる前記リソースを用いて前記カレントスレッドに前記リソースを割り当てる段階とを更に備える請求項８に記載の機械可読な媒体。
15. マルチスレッディングオペレーションの実行ができるプロセッサと、前記プロセッサに結合するメモリを備え、前記メモリから前記プロセッサによって実行される処理が、前記プロセッサに、
    データ処理ユニット中の一つ以上の実行ファイルを有するコードの編集中に、最も下部の順を有するカレントスレッドを選択し、
    前記カレントスレッドから生成された一つ以上の子スレッドに割り当てるリソースを決定し、
    前記カレントスレッドと当該カレントスレッドの一つ以上の子スレッドとの間のリソースコンフリクトを避けるために、前記カレントスレッドの一つ以上の子スレッドに割り当てられたリソースに考慮して、前記カレントスレッドにリソースを割り当てることを引き起こすデータ処理システム。
16. 前記処理が、前記プロセッサに、前記カレントスレッドに割り当てられた前記リソースに関してのデータ構造中のリソース情報をアップデートすることを更に引き起こし、前記データ構造が前記カレントスレッドの親スレッドによってアクセス可能である請求項１５に記載のデータ処理システム。
17. 前記処理が、前記プロセッサに、一つ以上の前記スレッドのそれぞれが実行されるまで、ボトムアップの順に、前記選択段階、前記決定段階、および前記割り当て段階を繰り返すことを更に引き起こす請求項１６に記載のデータ処理システム。
18. 前記処理が、前記プロセッサに、前記一つ以上のスレッドのそれぞれが実行された後に、前記一つ以上のスレッドの親スレッドである主要スレッドにリソースを割り当てることを更に引き起こし、前記主要スレッドの前記リソースが、前記一つ以上のスレッドに割り当てられたりソースを考慮して割り当てられる請求項１７に記載のデータ処理システム。
19. 前記処理が、前記プロセッサに、
    前記カレントスレッドに前記リソースを割り当てる前記段階に優先して、前記データ処理システム内にリソースが残っているか否か決定し、
    前記カレントスレッドの少なくとも一つの子スレッドを消去し、
    前記少なくとも一つの消去された子スレッドに関連付けられる前記リソースを用いて前記カレントスレッドに前記リソースを割り当てることを更に引き起こす請求項１５に記載のデータ処理システム。
20. 前記リソースが、前記隠すレッドによって使用される少なくとも一つのハードウエアレジスタおよびメモリを含む請求項１５に記載のデータ処理システム。

Images