JP2014038408A - 同時マルチスレッディング機能をもったプロセッサのパイプラインにおけるストール削減方法、削減装置及び削減プログラム - Google Patents

Abstract

【課題】アウト・オブ・オーダーのプロセッサにおけるレジスタ依存以外のデータ依存を原因とするストールの発生を抑制する技術を提供する。
【解決手段】ストール削減プログラム３００は、ＰＭＵ３１４を利用して実行コード３０８の実行中に生じたストールを検出し、ストールを起こした第１命令がデータ依存する第２命令をその依存関係から特定するハンドラ３１２と、第２命令をプロファイル情報３１６として記録するプロファイラ３１０と、プロファイル情報３１６に基づき実行コード３０８又はオリジナルのコード・ファイル３０６内の適切な位置にthread yield命令を挿入し、最適化済み実行コード３２０を出力する最適化モジュール３１８とを含む。
【選択図】図３

Description

本発明は、アウト・オブ・オーダー実行を行うプロセッサにおいて観測されるパイプラインにおけるストールの発生を削減する技術に関する。特に本発明は、同時マルチスレッディング（ｓｉｍｕｌｔａｎｅｏｕｓ ｍｕｌｔｉｔｈｒｅａｄｉｎｇ：ＳＭＴ）技術における複数スレッドの同時実行を利用して、そのようなストールの発生を削減する技術に関する。

従来多くの高性能のプロセッサにおいて、命令実行効率を上げるためにアウト・オブ・オーダー実行が採用されている。アウト・オブ・オーダー実行では、命令はデータ順、即ち、データないしオペランドがプロセッサのレジスタに用意される順序で処理される。アウト・オブ・オーダーのプロセッサは、順序通り命令を実行したのと同じ結果が得られるように、後に実行結果の順序を修正する。

しかしながら、アウト・オブ・オーダーのプロセッサにおいても、データ依存性を損なう順で命令が実行されストールが発生することがある。原因は、命令ウィンドウの上限といったデータの依存関係をチェックするためのハードウェアの制約であり、高速処理できる依存の複雑さには上限がある。上記問題をソフトウェアによるコードの最適化によって軽減することもできるが、ソフトウェア要素が多数組み合わさって動作する場合の要素間にまたがるデータ依存性や、関数間にまたがるデータの依存性は依然として解析困難である。

パイプラインにおけるストールの問題を解決するためのいくつかの従来技術が存在する。特許文献１は、同時マルチスレッディング・マイクロプロセッサにおいて、プロセッサ内の複数のパイプラインにおける複数の判定ポイント間で、いずれのスレッドの命令を選択するかを決めるスレッド選択優先度を同期させ、それによってシステム全体のパフォーマンスと消費電力を改善する技術を開示する。

また、特許文献２は、第１スレッドの解析によってパイプライン・ストールを起こしうる命令としてレイテンシの長い命令を識別し、識別した命令の実行後にスレッド切り替え命令を挿入することで、長いレイテンシを隠す技術を開示する。

また特許文献３は、同時マルチスレッディングのプロセッサにおいて、各スレッドからの命令に対してレジスタ依存を計算して命令ごとに実行優先度を求め、求めた実行優先度に基づいてディスパッチする命令を選択することで、ストールなく命令を実行できる技術を開示する。

また、特許文献４は、マルチコンテキストをサポートするプロセッサにおいて、パイプラインにあるコンテキストの命令を流して実行すると共に、パイプラインの空きを判断した場合に実行途中にある別のコンテキストに切り替えて同時に複数のコンテキストを実行させる技術を開示する。より具体的には、特許文献４は、コンテキスト切り替えの契機となるロード命令と分岐命令の実行に必要な情報として、それぞれの命令のレイテンシ分のインターバルをもつ先行する命令コードの属性情報フィールドに、各命令の実行途中にある別のコンテキストの命令フェッチを指示する属性情報を設ける技術を開示する。

米国特許出願公開第２０１０／００１７８５２号明細書 米国特許出願公開第２００８／０２６３３２５号明細書 米国特許出願公開第２００６／０１７９２８０号明細書 特開８−１４７１６５号公報

しかしながら、特許文献１が開示する技術は、ストールしがちなスレッドの実行を抑制するものであるため、他のスレッドの命令の実行によってＣＰＵ実行効率を向上させることはできるが、データ依存性を損なう順で命令が実行されることにより生ずるストールを抑制することはできない。また、特許文献２及び４が開示する技術は、実行した命令のレイテンシを隠すためにスレッドの発生をトリガーとして他のスレッドの命令を投入する技術であるため、ストールそれ自体を抑制することはできない。

一方、特許文献２が開示する技術によれば、命令のレジスタ依存を計算して入力値が計算される前に命令を投入しないようにすることでストールの発生を防ぐことができる。しかしながら、特許文献２では、パイプラインに投入しても実行できない命令をその命令のレジスタ依存性によって決定するため、レジスタ依存以外のデータ依存関係により生ずるストールを抑制することができない。

この発明は、上記の問題点を解決するためになされたものであって、アウト・オブ・オーダーのプロセッサにおいて生ずるレジスタ依存以外のデータ依存を原因とするストールの発生を抑制するための技術を提供することを目的とする。

上記課題を解決するために、本願発明者は、最初のストール発生時において、ストールした命令がデータ依存する命令をそのデータ依存関係から特定して記録しておき、次回以降はデータ依存する命令がフェッチされてからストールした命令がフェッチされるまでの間にデータが準備されるように、記録したデータ依存する命令の次回以降の実行に対し実行中のスレッドと異なる他のスレッドのフェッチを指示する命令を挿入するというアイデアに想到した。

即ち、上記目的を達成する本発明は、次のような、コンピュータ処理により、同時マルチスレッディング機能をもったプロセッサのパイプラインにおけるストールを削減する方法によって実現される。そのようなストール削減方法は、コンピュータが、ストールの発生を検出するステップと、コンピュータが、前記ストールを発生させた命令（以下、「第１命令」という）がデータ依存する他の命令（以下、「第２命令」という）をそのデータ依存性から特定するステップと、コンピュータが、特定された前記第２命令を記録するステップと、コンピュータが、第２命令がフェッチされてから第１命令がフェッチされるまでに実行中のスレッドの切り替えが行われるように、記録された前記第２の命令の次回以降の実行に対し前記実行中のスレッドと異なる他のスレッドのフェッチを指示する命令を挿入するステップとを含む。

好ましくは、前記ストールの発生の検出は、パフォーマンス監視ユニットのハードウェア・イベントである前記パイプラインへの命令投入待機イベント又はパイプライン処理のキャンセルのイベントのいずれかのイベントの検出により行われる。

より好ましくは、前記第２命令の特定は、前記イベントの検出に応答して、実行プログラムにおいて前記第１命令を始点として１つ前の命令を順次解析対象とし、前記第１命令から所定数内の命令を解析することに行われる。

更に好ましくは、現在の前記解析対象がコール命令の場合、呼び出された関数のリターン命令が前記現在の解析対象に設定され、前記現在の解析対象が分岐ターゲットである場合、対応する分岐元命令が前記現在の解析対象に設定され、及び前記解析対象が関数の先頭である場合、コール・スタックを調べて前記関数を呼び出したコール命令が前記現在の解析対象に設定される。

また好ましくは、前記第２命令は第１命令とペアにして記録され、かつその記録回数がカウントされ、前記他のスレッドのフェッチを指示する命令の挿入は、カウントされた記録回数が閾値を超えたペアに対して実行される。

また好ましくは、前記他のスレッドのフェッチを指示する命令は、実行中のスレッドの優先度引き下げを指示する命令により実現されてよく、また、バイナリ変換又は再コンパイルにより、動的に又は静的に前記第１命令より前に挿入される。

なお、これまで同時マルチスレッディング機能をもったプロセッサのパイプラインにおけるストールを削減する方法として本発明を説明した。しかし本発明は、上記ストール削減方法をコンピュータに実行させるためのストール削減プログラムとして把握することもできる。また本発明は、上記ストール削減方法を実施するシステムとして把握することもできる。

また、上記目的を達成する本発明は、次のような、同時マルチスレッディング機能をもったプロセッサのパイプラインにおけるストールを削減するストール削減装置によって実現される。そのようなストール削減装置は、スレッドごとに用意されたバッファからスレッドの優先度に従って命令をフェッチするフェッチ・ユニットと、フェッチされた命令をデコードするデコード・ユニットと、デコードされた命令をアウト・オブ・オーダーに実行し、各々実行中の命令のストールを検出可能な複数の実行ユニットとを含む。そして、前記各実行ユニットは、ストールの検出に応答して実行中の命令（以下、「第１命令」という）がデータ依存する他の命令（以下、「第２命令」という）をそのデータ依存性から特定し、記録する。また、前記フェッチ・ユニットは、フェッチした命令が記録された第２命令であるか否かを判定し、第２命令であるとの判定に応答して、次に前記第１命令をフェッチするまでに実行中のスレッドの切り替えを行う。

好ましくは、上記ストール削減装置は、命令と該命令が使用する前記プロセッサのリソース情報とのペアが各命令の実行時にインオーダー順に登録されるテーブルを更に含む。そして前記各実行ユニットは、前記第１命令が使用する前記コンピュータのリソース情報をキーとして前記第１命令よりも先に前記テーブルに登録されたエントリに対して検索を行うことにより前記第２命令を特定する。

また好ましくは、前記第２命令の記録は、所定のテーブルにそのアドレスを保存すること、若しくは命令キャッシュラインの１ビットを利用すること、又はそれらの組み合わせによりなされる。

また好ましくは、上記ストール削減装置は、実行結果をキャッシュやメモリなどの所定の記憶領域に書き込むリタイア・ユニットを更に含む。そして前記第２命令の記録は、前記第２命令に対する前記リタイア・ユニットによる処理が正常終了することを条件としてなされる。

また好ましくは、前記フェッチ・ユニットは、前記実行中のスレッドのバッファからフェッチした命令が、記録された前記第２命令に一致することに応答して、フェッチするバッファを、実行準備が整っている他のスレッドのバッファに切り替えてもよい。これに代えてフェッチ・ユニットは、前記実行中のスレッドのバッファからフェッチした命令が、記録された前記第２命令に一致することに応答して、前記実行中のスレッドと異なる他のスレッドのフェッチを指示する命令や、前記実行中のスレッドの優先度引き下げを支持する命令を挿入してもよい。

本願発明は、最初のストール発生時において、ストールした命令がデータ依存する命令をそのデータ依存関係から特定して記録しておき、記録されたデータ依存する命令の次回以降の実行に対し実行中のスレッドと異なる他のスレッドのフェッチを指示する命令を挿入する。このため、本願発明の構成によれば、データ依存する命令がフェッチされてからストールした命令がフェッチされるまでに実行中のスレッドの切り替えが行われることになり、アウト・オブ・オーダーのプロセッサにおいて生ずるレジスタ依存以外のデータ依存を原因とするストールの発生を抑制することができる。本願発明のその他の効果については、各実施の形態の記載から理解される。

パイプラインがストールするとフラッシュするペナルティを模式的に示した図である。 本発明の適用によりストールが回避される様子を模式的に示した図である。 本発明の実施形態に係るプロセッサのパイプライン構造とその周辺環境を示す図である。 本発明の実施形態に係るプロセッサにおいてストールが生じた際の各要素の動作の一例を説明する図である。 本発明の実施形態に係るストール削減プログラムのソフトウェア構成を示す図である。 実行対象プログラムがオフラインで存在する場合における、本発明の実施形態に係るストール削減プログラムのソフトウェア構成を説明する図である。 実行対象プログラムが動的に変更する場合における、本発明の実施形態に係るストール削減プログラムのソフトウェア構成の一例を説明する図である。 実行対象プログラムが動的に変更する場合における、本発明の実施形態に係るストール削減プログラムのソフトウェア構成の他の例を説明する図である。 本発明の実施形態に係るストール削減処理全体の動作フローの一例を示す。 本発明の実施形態に係るコンピュータシステム６００のハードウェア構成の一例を示す。

以下、本発明の実施形態を図面に基づいて詳細に説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。なお、実施の形態の説明の全体を通じて同じ要素には同じ番号を付している。

図１Ａにパイプラインがストールするとフラッシュするペナルティの一例を模式的に示す。図１Ａにおいて横軸はプロセッサのサイクルを示し、縦軸はプロセッサのパイプラインの各ステージを示す（各ステージの処理結果は下のステージに渡される）。また、矩形の横縞はそのステージがスレッド１の命令で埋まっていることを示し、矩形の縦縞はそのステージがスレッド２の命令で埋まっていることを示している。なお、図１Ａではパイプラインはその一部を示しており、最終ステージは示されていないことに留意されたい。

図１Ａでは、２サイクル目において上から３番目のステージ２０で命令Ａを処理中にストールが発生している。原因は矢印２２が示すように、１サイクル目において上から５番目のステージ２４で処理されていた命令Ｂの実行結果が、２サイクル目においてステージ２０で処理されている命令Ａに対してまだ利用可能とはなっていなかったためである。このような状況は、アウト・オブ・オーダー実行のプロセッサにおいてデータ依存性を損なう順で命令が実行されると起こり得る。

結果、図１Ａに示す例では、ペナルティとしてストールが発生した２サイクル目から次の４サイクルの間（矢印２６参照）新たな命令が投入されず、かつ、ストールしたステージ２０を含むそれ以前のステージの処理結果が全て無効化される。このようにストールによってパイプラインが命令を効率的に実行できない状態になるとプロセッサの性能が落ちる。そのためストールが頻発すると重大な性能の低下に繋がる。

そこで本発明では、最初のストール発生時において、ストールした命令がデータ依存する命令をそのデータ依存関係から特定して記録しておき、記録されたデータ依存する命令の次回以降の実行に対し実行中のスレッドと異なる他のスレッドのフェッチを指示する命令を挿入することとした。該構成によれば、データ依存する命令がフェッチされてからストールした命令がフェッチされるまでに実行中のスレッドの切り替えが行われるようになるため、データ依存する命令の実行が開始されてからストールした命令の実行が開始されるまで十分な時間間隔が得られるようになる。結果、ストールした命令が実行される際にはデータ依存する命令の実行結果が利用可能な状態になっており、ストールの回避が可能となる。

上記本発明は、ハードウェアにより実装することも、ハードウェアの機能を一部利用してソフトウェアにより実装することもどちらも可能である。以下では前者を第１実施形態、後者を第２実施形態として順に説明する。

（第１実施形態）
図２Ａは、本発明の実施形態に係るプロセッサ２００のパイプライン構造とその周辺環境を示す図である。プロセッサ２００は、同時マルチスレッディング機能をもち、アウト・オブ・オーダー実行を採用する。プロセッサ２００のパイプラインは、フェッチ・ユニット２０４、デコード・ユニット２０６、ディスパッチ・ユニット２０８、複数の実行ユニット２１２〜２２２、及びリタイア・ユニット２２４を含む。なお、図２Ａに示す例ではパイプラインが途中２つに分かれており、それぞれの実行パイプラインは３つの実行ユニットより構成されているが、本発明を実施するのにパイプラインの分岐数や実行ユニット数に制限はないことに留意されたい。また、プロセッサ２００は、図２Ａに図示しない他の構成要素を含んでよいことは言うまでもない。

フェッチ・ユニット２０４は、スレッドごとに用意された命令バッファ２０２からスレッドの優先度に従って命令をフェッチする。スレッドの優先度はその命令を処理すべき優先度に応じて設定され、状況に応じて変更されうる。デコード・ユニット２０６は、フェッチされた命令をデコードする。

ディスパッチ・ユニット２０８は、その処理に必要な全てのデータないしオペランドが図示しないプロセッサ２００のレジスタに用意される順序で、デコードされた命令を適切な実行ユニットにディスパッチする。このときディスパッチされる命令は、元のプログラムと同じ順番でリタイアするためにリオーダ・バッファ２１０に登録される。

複数の実行ユニット２１２〜２２２は各々ディスパッチされた命令を実行する。実行ユニット２１２〜２２２は具体的には、図示しないメモリからの値のロード及びストアを行うロード・ストア実行ユニットや、図示しないレジスタが保持する値に加減算やシフトを行う整数演算ユニットであってよい。

リタイア・ユニット２２４は、各命令の最終的な実行結果を図示しないキャッシュやメモリなどの所定の記憶領域に書き込む。リタイア・ユニット２２４による処理が終了すると各命令は実行完了の状態になり、上述したリオーダ・バッファ２１０から削除される。但し、リオーダ・バッファ２１０からの削除には追加の条件が課される場合もある。

また、本発明の実施形態に係るプロセッサ２００はメモリ２２６を含み、メモリ２２６内にリソース・テーブル２２８を保持する。リソース・テーブル２２８には、命令と該命令が使用するプロセッサ２００のリソース情報とのペアが、命令の実行時にリソースごとにインオーダー順（即ち、プログラム順）に登録される。ここで、本発明の実施形態に係るプロセッサ２００の各実行ユニット２１２〜２２２は、命令を処理する際にストールの発生を検出すると、ストールを起こしたその命令（以下、「第１命令」という）がデータ依存する他の命令（以下、「第２命令」という）をそのデータ依存性から特定して記録する。

より具体的には、各実行ユニット２１２〜２２２は、自身の実行ユニットでストールの発生を検出すると、第１命令が使用するリソース情報（典型的にはメモリのアドレス）をキーとして、第１命令よりも先にリソース・テーブル２２８に登録されたすべてのエントリに対して検索を行うことにより第２命令を特定する。なお、特定される命令が複数存在する場合は、リソース・テーブル２２８内における登録位置が第１命令のエントリに最も近いものを選択する。このように第１命令がデータ依存する第２命令は、第１命令がアクセスするメモリと同一のメモリアドレスにアクセスし、プログラム順において第１命令に先行しかつ第１命令に最も近い命令を見つけることによって特定できる

実行ユニット２１２〜２２２は、特定した第２命令を記録する。第２命令の記録は、メモリ２２６内のデータ依存命令テーブル２３０に第２命令のアドレスを登録すること、若しくは命令キャッシュラインの１ビットを利用すること、又はそれら２つの組み合わせにより行ってよい。上記２つの組み合わせでは、最初はデータ依存命令テーブル２３０に第２命令の情報を保存しておき、命令のデコード時にデコードした命令がデータ依存命令テーブル２３０に登録されている命令と一致することが判明すると、その時点で第２命令を命令キャッシュラインの１ビットを利用して記録する。

なお、上記構成に代えて、第２命令の記録は、第２命令に対するリタイア・ユニット２２４による処理が正常終了することを条件としてリタイア・ユニット２２４の指示により行ってもよい。この場合実行ユニット２１２〜２２２は、データ依存する命令を特定するとその時点では命令をマークするに留める。特定した命令のマークは、パイプライン上に流れる情報を追加したり、専用レジスタに特定した命令を保存したり、或いはリオーダ・バッファ２１０内の特定した命令のエントリをマークすることにより行ってよい。これは、投機的に実行され最終的にはキャンセルされる命令を本発明の適用対象から除くためである。但し、投機的に実行される命令であってもパイプライン上の他の命令に影響を与える命令である限り、本発明を適用することによって効果は得られる。

また本発明の実施形態に係るプロセッサ２００のフェッチ・ユニット２０４は、その処理の際にフェッチした命令が記録された第２命令であるか否かを判定し、第２命令であるとの判定に応答して、現在処理中のスレッドと異なる他のスレッドのフェッチを指示する命令（以下、スレッド切り替え命令という）を挿入する。これは第２命令をフェッチしてから次に第１命令をフェッチするまでに実行中のスレッドの切り替えが行われるようにするためである。なお、スレッド切り替え命令は、現在処理中のスレッドの優先度の引き下げを指示する命令（以下、thread yield命令という）によって実現してもよい。以下では、スレッド切り替え命令としてthread yield命令を用いる場合について説明する。

フェッチ・ユニット２０４により挿入されたthread yield命令は、デコード・ユニット２０６により識別され、デコード・ユニット２０６はフェッチ・ユニット２０４に対して現在処理中のスレッドの優先度の引き下げを指示する。これに代えて、thread yield命令は、リタイア・ユニット２２４により識別し、リタイア・ユニット２２４はフェッチ・ユニット２０４に対して、現在処理中のスレッドの優先度の引き下げを指示してもよい。

なお、フェッチ・ユニット２０４によるthread yield命令の挿入位置は、第２命令がフェッチされた後次に第１命令をフェッチするまでにフェッチ対象スレッドを切り替えることのできる位置である。具体的には、thread yield命令フェッチから優先度切り替えが起きるまでに要するサイクル数だけ第１命令より前方である。そこで上記方法に代えて、フェッチ・ユニット２０４は、その処理の際にフェッチした命令が記録された第２命令であるか否かを判定し、第２命令であるとの判定に応答すると、thread yield命令を挿入することなく直接フェッチするバッファを実行準備が整っている他のスレッドのバッファに切り替えてもよい。

次に図２Ｂを参照して、上述したプロセッサ２００のパイプラインにおいてストールが生じた際の各構成要素の動作を説明する。図２Ｂに示す例では、実行ユニット２１４において命令Ａの処理中にストールが生じたとする。実行ユニット２１４は、ストールの検出に応答してリソース・テーブル２２８を参照し（番号１参照）、実行中の命令Ａがデータ依存する他の命令Ｂを特定し（番号２参照）、特定した命令Ｂの情報をデータ依存命令テーブル２３０に記録する（番号３参照）。

フェッチ・ユニット２０４は命令バッファ２０２から次の命令をフェッチする度に、データ依存命令テーブル２３０を参照してフェッチした命令が登録されたいずれかの命令に一致するか否かを判定する（番号４参照）。フェッチした命令がデータ依存命令テーブル２３０に登録された命令Ｂであった場合、フェッチ・ユニット２０４は次に命令Ａをフェッチするまでに実行中のスレッドの切り替えが行われるように、実行中のスレッドの優先度の引き下げを指示するthread yield命令Ｃを挿入する（番号５参照）。

デコード・ユニット２０６はデコードした命令がthread yield命令Ｃであることを識別すると、フェッチ・ユニット２０４に対して実行中のスレッドの優先度の引き下げを指示する（番号６参照）。フェッチ・ユニット２０４は、デコード・ユニット２０６の指示に応答して実行中のスレッドの優先度を引き下げる。以降、フェッチ・ユニット２０４は更新されたスレッドの優先度に従って、スレッドごとに用意された命令バッファ２０２から命令をフェッチする。なお、上述したように、thread yield命令Ｃの識別及び実行中のスレッドの優先度の引き下げ指示は、リタイア・ユニット２２４により行ってもよい（番号６’参照）。また、フェッチ・ユニット２０４は、フェッチした命令がデータ依存命令テーブル２３０に登録された命令に一致すると判定した場合、直ちに実行準備が整っている他のスレッドの命令バッファから命令をフェッチしてもよい。

本発明による効果を、図１Ｂを参照して説明する。図１Ｂは本発明の適用によりストールが回避される様子を模式的に示した図である。図１Ａと同様に、図１Ｂにおいて横軸はプロセッサのサイクルを示し、縦軸はプロセッサのパイプラインの各ステージを示す（各ステージの処理結果は下のステージに渡される）。また、矩形の横縞はそのステージがスレッド１の命令で埋まっていることを示し、矩形の縦縞はそのステージがスレッド２の命令で埋まっていることを示す。ここで命令Ｃは、フェッチ・ユニット２０４により挿入されたthread yield命令を示す。また命令Ｂは、以前にストールを起こした命令Ａがデータ依存する命令を示す。なお、図１Ｂでは、パイプライン全体が示されていることに留意されたい。

図１Ｂに示す例では、挿入されたthread yield命令が最終ステージ、即ちリタイア・ユニット２２４により３サイクル目に処理される。その際リタイア・ユニット２２４からフェッチ・ユニット２０４に対し処理中のスレッド２の優先度の引き下げが指示され、結果、次の４サイクル目においてスレッド１の命令のフェッチが開始されている。

４サイクル目以降、スレッド２の命令は優先度の引き下げによりフェッチ対象とならず、矢印３６で示されるように続く７サイクルの間はスレッド１の命令のみがパイプラインへ新たに投入される。そして１１サイクル目においてようやくスレッド２の優先度が回復し、以前ストールを起こした命令Ａがフェッチされている。結果、データ依存する命令Ｂの実行（或いはフェッチ）から命令Ａのフェッチまでに十分な時間間隔が存在することになり、ストールが回避される。

（第２実施形態）
図３は、本発明の実施形態に係るストール削減プログラム３００のソフトウェア構成を説明する図である。本発明の実施形態に係るストール削減プログラム３００は、ハードウェアの機能を利用して実行コード３０８の実行中に生じたストールを検出し、ストールを起こした第１命令がデータ依存する第２命令を特定するハンドラ３１２と、ハンドラ３１２が特定した第２命令をプロファイル情報３１６として記録するプロファイラ３１０と、プロファイル情報３１６に基づいて実行コード３０８又はオリジナルのコード・ファイル３０６内の適切な位置にスレッド切り替え命令を挿入し、最適化済み実行コード３２０を出力する最適化モジュール３１８とを含む。第１実施形態に関して説明したように、スレッド切り替え命令は、thread yield命令により実現してもよい。以下では、スレッド切り替え命令としてthreadyield命令を用いる場合について説明する。

ここでハンドラ３１２により利用されるハードウェアの機能とは、ＣＰＵ３０２により提供されるパフォーマンス監視部（ｐｅｒｆｏｒｍａｎｃｅｍｏｎｉｔｏｒｉｎｇ ｕｎｉｔ：ＰＭＵ）３１４の機能である。ＰＭＵ３１４は、ＣＰＵ３０２内部の挙動について指定されたイベントの発生を監視し、内部カウンタによりイベントの発生をカウントしたり、カウント値が閾値に達したときに指定された処理を行ったりする。監視対象の代表的なものとしては、ＣＰＵ３０２の実行サイクル数、実行命令数、分岐予測ミス数、データキャッシュミス数などがある。なお、ＣＰＵ３０２は、同時マルチスレッディング機能をもち、アウト・オブ・オーダー実行を採用するプロセッサである。

本発明では前処理として後述するプロファイラ３１０により、ＰＭＵ３１４に対し監視したいハードウェア・イベントとしてパイプラインへの命令投入待機イベント及びパイプライン処理のキャンセルのイベント少なくとも一方を指定する。ここでパイプライン処理のキャンセルのイベントは、実行完了前のキャンセルのイベントと、実行完了後のキャンセル、即ち実行結果の無効化処理のイベントの両方を含む。また、プロファイラ３１０はＰＭＵ３１４に対し、指定したイベントの回数が閾値に達したときに後述するハンドラ３１２を起動するように指定する。ＰＭＵ３１４は、ハンドラ３１２を起動する際に、指定されたイベントを起こした命令、即ちストールを起こした第１命令のポインタを報告する。

ハンドラ３１２は、ＰＭＵ３１４により起動されると、報告されたポインタが指す第１命令をロードし、デコードし、必要に応じてその命令の種類、オペランドの種類、及び使用するレジスタ番号を取得する。ハンドラ３１２は、これらの情報を用いて後述する、第1命令がアクセスするＨＷ資源の識別情報を取得する。そしてハンドラ３１２は、現在実行中の実行コード３０８において第１命令を始点として１つ前の命令を順次解析対象とし、第１命令から所定数内の命令を解析することにより第１命令がデータ依存する第２命令を特定する。ストールを起こすことから第１命令がデータ依存する第２命令は、実行コード３０８中第１命令に先行しかつ第１命令に近い位置にあると考えられる。そのため上記所定数としては、１０〜２０命令数で十分である。

なお、現在の解析対象がコール命令の場合、ハンドラ３１２は呼び出された関数のリターン命令を現在の解析対象に設定する。また現在の解析対象が分岐ターゲットである場合、ハンドラ３１２は対応する分岐元命令を現在の解析対象に設定する。また現在の解析対象が関数の先頭である場合、ハンドラ３１２はコール・スタックを調べて関数を呼び出したコール命令を現在の解析対象に設定する。

またハンドラ３１２は、現在の解析対象がデータ依存する第２命令であるか否かを次のようにして解析する。まずハンドラ３１２は、第1命令がアクセスするＨＷ資源の識別情報と、データ依存の種類をＰＭＵ３１４から取得する。ここでデータ依存の種類は同じＨＷ資源に対してなされた２つのアクセスの方法と順番を示し、(Write, Read)、(Read, Write)、(Write,Write)、(Read,Read)のいずれかを示す。但し（１番目のアクセスの方法、２番目のアクセス方法）であり、1番目のアクセスは第２命令によるものであり、２番目のアクセスは第1命令によるものである。そしてハンドラ３１２は、現在の解析対象の命令をデコードし、その命令が、第1命令がアクセスするＨＷ資源と同じＨＷ資源をアクセスし、しかもアクセスの方法がデータ依存の１番目のアクセス方法と一致するか否かを調べる。これらの条件を満たす場合現在の解析対象は第２命令であり、そうでない場合現在の解析対象は第２命令でない。ＨＷ資源はレジスタ、キャッシュ、メモリ、実行ユニット、制御ユニットのいずれかである。

第２命令が特定できた場合、ハンドラ３１２は第２命令の情報をプロファイラ３１０に報告する。

プロファイラ３１０は、ハンドラ３１２から第２命令の情報を受け取ると、これをプロファイル情報３１６として記録する。第２命令は第１命令とのペアとして通知されてもよく、プロファイラ３１０は、ペアごとにその通知の頻度など統計情報を求めて記録してもよい。また第２命令の情報は、命令のアドレス情報など、実行コード３０８又はそのオリジナルのコード・ファイル３０６内における第２命令の位置情報が分かるものであればよい。

最適化モジュール３１８は、プロファイル情報３１６を参照して、実行コード３０８又はそのオリジナルのコード・ファイル３０６内の適切な位置に実行中のスレッドの優先度を引き下げるthread yield命令を挿入する。thread yield命令の挿入は、第１命令と第２命令のペアについての統計情報が閾値を超えることを条件に行ってもよい。なお、thread yield命令を挿入する適切な位置とは、第２命令がフェッチされた後次に第１命令をフェッチするまでにフェッチ対象スレッドを切り替えることのできる位置である。

また、thread yield命令の挿入を静的に行うか又は動的に行うかは、実行コード３０８が静的に存在するか又は動的に変更されるものとして存在するか、即ち、実行コード３０８が再配置可能であるか否かによる。前者の場合については図４Ａを参照して、また後者の場合については図４Ｂ及び図４Ｃを参照して、最適化処理を説明する。

図４Ａは、実行コード３０８がオフラインで存在する場合における、本発明の実施形態に係るストール削減プログラムのソフトウェア構成を説明する図である。ＣＰＵ４０２、ＰＭＵ４１２、ＯＳ４０４、ハンドラ４１４、プロファイラ４１０については、図３を参照して説明したのと変わらないのでここでは説明を省略する。実行コード３０８はバイナリコード４０８として存在し、最適化装置４１８（最適化モジュール３１８に対応）はオフラインでバイナリコード・ファイル４０６を変換し、プロファイル情報４１６を参照して適切な位置にthread yield命令を挿入する。そして最適化装置４１８は、threadyield命令を挿入されたバイナリコード・ファイルを最適化済みバイナリコード・ファイル４２０として出力する。

なお、バイナリコード４０８のソースコード・ファイル４２２が存在する場合、最適化装置４１８はソースコード・ファイル４２２からバイナリコードに変換する際にプロファイル情報４１６を参照して、thread yield命令を挿入すべき位置が含まれると判断するとthreadyield命令を挿入し、最適化済みバイナリコード・ファイル４２０を出力する。

図４Ｂは、実行対象プログラムが動的に変更する場合における、本発明の実施形態に係るストール削減プログラムのソフトウェア構成の一例を説明する図である。ＣＰＵ４０２、ＰＭＵ４１２、ＯＳ４０４、ハンドラ４１４、プロファイラ４１０については、図３を参照して説明したのと変わらないのでここでは説明を省略する。実行コード３０８はバイトコード・ファイル４３０として存在し、インタプリタ４３２により逐次解釈され、実行頻度の高いバイトコードはＪＩＴコンパイラ４３４によりバイナリコードに変換されＣＰＵで直接実行される。ＪＩＴコンパイラ４３４（最適化モジュール３１８に対応）はプロファイル情報４１６を参照し、コンパイルしたバイナリコードにthread yield命令を挿入すべき適切な位置が含まれると判断すると、動的に再コンパイルしてthread yield命令を挿入して、最適化済みコード４３６を出力する。

図４Ｃは、実行対象プログラムが動的に変更する場合における、本発明の実施形態に係るストール削減プログラムのソフトウェア構成の他の一例を説明する図である。ＣＰＵ４０２、ＰＭＵ４１２、ＯＳ４０４、ハンドラ４１４、プロファイラ４１０については、図３を参照して説明したのと変わらないのでここでは説明を省略する。実行コード３０８はバイナリコード４４２として存在し、動的バイナリ変換（Ｄｙｎａｍｉｃ Ｂｉｎａｒｙ Ｔｒａｎｓｌａｔｉｏｎ：ＤＢＴ）４４４は、バイナリコード４４２を実行時に現在の環境において実行可能なバイナリに変換する。ＤＢＴ４４４（最適化モジュール３１８に対応）はプロファイル情報４１６を参照し、次に実行するバイナリコード部分にthread yield命令を挿入すべき適切な位置が含まれると判断すると、threadyield命令を挿入してバイナリ変換し、最適化済みコード４４６を出力する。

次に図５を参照して、本発明の実施形態に係るストール削減プログラム３００によるストール削減処理を説明する。図５は、本発明の実施形態に係るストール削減処理全体の動作フローの一例を示す。

図５に示すストール削減処理はステップ５００から開始し、プロファイラ３１０は調査したいＰＭＵ３１４のハードウェア・イベントとして、パイプラインへの命令投入待機イベント及びパイプライン処理のキャンセルのイベントの少なくとも一方を指定する。ＰＭＵ３１４は、指定されたハードウェア・イベントをカウントし、閾値を超えた時点で同様にプロファイラ３１０により指定されたハンドラ３１２を起動する（ステップ５０２）。起動されたハンドラ３１２は、ＰＭＵ３１４を調べて指定したハードウェア・イベントを起こした第１命令を取得する（ステップ５０４）。

続いてハンドラ３１２は、取得した第１命令をコード解析現在値に設定する（ステップ５０６）。続いてハンドラ３１２は、実行コード３０８内においてコード解析現在値を始点として１つ前の命令を新たにコード解析現在値に設定する（ステップ５０８）。続いてハンドラ３１２は、コード解析現在値がコール命令であるか否かを判定する（ステップ５１０）。コード解析現在値がコール命令である場合（ステップ５１０：ＹＥＳ）、ハンドラ３１２は、コール命令の分岐先関数のリターン命令を新たにコード調査現在値に設定し（ステップ５１２）、再びステップ５０８の処理へ戻る。コール命令分岐先が静的に解析できない場合、一般的に用いられるコール分岐木のプロファイルを収集し、最も可能性のある分岐先を決定する。

一方、コード解析現在値がコール命令でない場合（ステップ５１０：ＮＯ）、続いてハンドラ３１２はコード解析現在値が分岐ターゲットであるか否かを判定する（ステップ５１４）。コード解析現在値が分岐ターゲットである場合（ステップ５１４：ＹＥＳ）、ハンドラ３１２は、分岐元命令を新たにコード解析現在値に設定し（ステップ５１６）、再びステップ５０８の処理へ戻る。分岐元が静的に解析できない場合、一般的に用いられる分岐のプロファイルを収集し、最も可能性のある分岐元を決定する。

一方、コード解析現在値が分岐ターゲットでない場合（ステップ５１４：ＮＯ）、続いてハンドラ３１２はコード解析現在値が関数の先頭であるか否かを判定する（ステップ５１８）。コード解析現在値が関数の先頭である場合（ステップ５１８：ＹＥＳ）、ハンドラ３１２は、コール・スタックを調べて関数を呼び出したコール命令を現在の解析対象に設定し（ステップ５２０）、再びステップ５０８の処理へ戻る。

コード解析現在値が関数の先頭でもなかった場合（ステップ５１８：ＮＯ）、続いてハンドラ３１２は、コード解析現在値が、第１命令がデータ依存する第２命令であるか否かを判定する（ステップ５２２）。コード解析現在値が第２命令であると判定した場合（ステップ５２２：ＹＥＳ）、ハンドラ３１２は、コード解析現在値を第２命令として特定し、プロファイラ３１０に対して第２命令と第１命令のペアを通知してその頻度情報の更新を指示する（ステップ５２４）。

続いて処理はステップ５２４からステップ５２６へ進み、プロファイラ３１０によるプロファイル情報の更新に応答して、最適化モジュール３１８は第２命令と第１命令のペアについての頻度が閾値を超えているか否かを判定する。閾値を超えている場合（ステップ５２６：ＹＥＳ）、最適化モジュール３１８はプロファイル情報を参照して、実行コード３０８又はそのオリジナルのコード・ファイル３０６内の適切な位置に実行中のスレッドの優先度を引き下げるthread yield命令を挿入する（ステップ５２８）。一方、閾値を超えていない場合（ステップ５２６：ＮＯ）、処理は終了する。

また、ステップ５２２においてコード解析現在値が第２命令でないと判定された場合（Ｓ５２２：ＮＯ）、続いてハンドラ３１２は解析した命令の数が所定数（例えば１０〜２０の間の数）に達したか否かを判定する（ステップ５３０）。解析した命令数が所定数に達していない場合（ステップ５３０：ＮＯ）、処理はステップ５０８へ戻る。一方、解析した命令の数が所定数に達している場合（ステップ５２６：ＹＥＳ）、処理は終了する。

図６は、本発明を実施するのに好適なコンピュータシステム６００のハードウェア構成の一例を示す。コンピュータ６００は、ＣＰＵ６０２とメイン・メモリ６０４とを備えており、これらはバス６０６に接続されている。ＣＰＵ６０２は同時マルチスレッディング機能をもち、アウト・オブ・オーダー実行を採用するものであり、例えばＩＢＭ社のＰＯＷＥＲ（商標）シリーズ、インテル社のＣｏｒｅ（商標）シリーズなどが使用されうる。バス６０６には、ディスプレイ・コントローラ６０８を介して、ディスプレイ６１０、例えば液晶ディスプレイ（ＬＣＤ）が接続されうる。ディスプレイ６１０は、コンピュータの管理のために、通信回線を介してネットワークに接続されたコンピュータについての情報と、そのコンピュータ上で動作中のソフトウェアについての情報を、適当なグラフィック・インタフェースで表示するために使用される。

バス６０６にはまた、ＳＡＴＡ又はＩＤＥコントローラ６１２を介して、ディスク６１４、例えばシリコン・ディスク又はハードディスクが接続されうる。また、バス６０６にはまた、ＳＡＴＡ又はＩＤＥコントローラ６１２を介して、任意的に、ドライブ６１６、例えばＣＤ、ＤＶＤ又はＢＤドライブが接続されうる。バス６０６にはさらに、任意的に、キーボード・マウスコントローラ６１８又はＵＳＢバス（図示せず）を介して、キーボード６２０及びマウス６２２が接続されうるが、本発明を実施する上では必要ない。

ディスク６１４には、オペレーティング・システム、本発明の実施形態に係るストール削減プログラム３００、その他のプログラム、及びデータが、メイン・メモリ６０４にロード可能なように記憶されている。オペレーティング・システムは、例えば、ＬＩＮＵＸ（登録商標）、マイクロソフト・コーポレーションが提供するＷｉｎｄｏｗｓ（登録商標）オペレーティング・システム、アップル・コンピュータ・インコーポレイテッドが提供するＭａｃＯＳ（登録商標）若しくはｉＯＳ（登録商標）、Ｘ Ｗｉｎｄｏｗ Ｓｙｓｔｅｍを備えるＵＮＩＸ（登録商標）系システム（たとえば、インターナショナル・ビジネス・マシーンズ・コーポレーション（登録商標）が提供するＡＩＸ（登録商標）でありうる。ドライブ６１６は、必要に応じて、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ又はＢＤからプログラムをディスク６１４にインストールするために使用されうる。

通信インタフェース６２６は、例えばイーサネット（登録商標）・プロトコルに従う。通信インタフェース６２６は、通信コントローラ６２４を介してバス６０６に接続され、コンピュータ６００を通信回線６２８に物理的に接続する役割を担い、コンピュータ６００のオペレーティング・システムの通信機能のＴＣＰ／ＩＰ通信プロトコルに対して、ネットワーク・インタフェース層を提供する。なお、通信回線は、有線ＬＡＮ環境に基づくもの、又は、無線ＬＡＮ環境、例えば、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎなどのＷｉ−Ｆｉ規格に基づくものであってもよい。

以上から、本発明の実施態様において使用されるコンピュータ６００は、特定のオペレーティング・システム環境に限定されるものではないことを理解することができるであろう。なお、上記説明した構成要素は例示であり、そのすべての構成要素が本発明の必須構成要素となるわけではない。

以上、実施形態を用いて本願発明の説明をしたが、本願発明の技術範囲は上記実施形態に記載の範囲には限定されない。上記の実施形態に、種々の変更又は改良を加えることが可能であることが当業者に明らかである。以上のように、上記の実施形態に変更又は改良を加えた形態も当然に本発明の技術的範囲に含まれる。

なお、特許請求の範囲、明細書、及び図面中において示した装置、システム、プログラム、及び方法における動作、手順、ステップ、及び段階等の各処理の実行順序は、特段「より前に」、「先立って」等と明示しておらず、また、前の処理の出力を後の処理で用いるのでない限り任意の順序で実現しうることに留意すべきである。また、前の処理の出力を後の処理で用いる場合でも、前の処理と後の処理の間に他の処理が入ることは可能である場合があること、又は間に他の処理が入るように記載されていても前の処理を後の処理の直前に行うよう変更することも可能である場合があることも留意されたい。特許請求の範囲、明細書、及び図面中の動作フローに関して、便宜上「まず、」、「次に、」、「続いて、」等を用いて説明したとしても、この順で実施することが必須であることを必ずしも意味するとは限らない。

Claims (14)

1. コンピュータ処理により、同時マルチスレッディング機能をもったプロセッサのパイプラインにおけるストールを削減する方法であって、
   コンピュータが、ストールの発生を検出するステップと、
   前記コンピュータが、前記ストールを発生させた命令（以下、「第１命令」という）がデータ依存する他の命令（以下、「第２命令」という）をそのデータ依存性から特定するステップと、
   前記コンピュータが、特定された前記第２命令を記録するステップと、
   前記コンピュータが、第２命令がフェッチされてから第１命令がフェッチされるまでに実行中のスレッドの切り替えが行われるように、記録された前記第２の命令の次回以降の実行に対し前記実行中のスレッドと異なる他のスレッドのフェッチを指示する命令を挿入するステップと、
   を含むストール削減方法。
2. 前記ストールの発生の検出は、前記パイプラインへの命令投入待機イベント又はパイプライン処理のキャンセルのイベントのいずれかの検出により行われる、請求項１に記載のストール削減方法。
3. 前記第２命令の特定は、実行プログラムにおいて前記第１命令を始点として１つ前の命令を順次解析対象とし、前記第１命令から所定数内の命令を解析することにより行われる、請求項２に記載のストール削減方法。
4. 現在の前記解析対象がコール命令の場合、呼び出された関数のリターン命令を前記現在の解析対象に設定し、前記現在の解析対象が分岐ターゲットである場合、対応する分岐元命令を前記現在の解析対象に設定し、及び前記現在の解析対象が関数の先頭である場合、コール・スタックを調べて前記関数を呼び出したコール命令を前記現在の解析対象に設定する、請求項３に記載のストール削減方法。
5. 前記第２命令は第１命令とペアにして記録され、かつその記録回数がカウントされ、
   前記他のスレッドのフェッチを指示する命令の挿入は、カウントされた記録回数が閾値を超えたペアに対して実行される、請求項４に記載のストール削減方法。
6. 前記他のスレッドのフェッチを指示する命令は、バイナリ変換又は再コンパイルにより、動的に又は静的に前記第２命令と前記第１命令の間に挿入される、請求項５に記載のストール削減方法。
7. 請求項１乃至６に記載のいずれかの方法の全ステップを実行するように適合された手段と、同時マルチスレッディング機能を有しアウト・オブ・オーダー実行するプロセッサとを含むシステム。
8. 請求項１乃至６に記載のいずれかの方法の全ステップを前記コンピュータに実行させる、同時マルチスレッディング機能をもったプロセッサのパイプラインにおけるストールの発生を削減するためのプログラム。
9. 同時マルチスレッディング機能をもったプロセッサのパイプラインにおけるストールを削減するストール削減装置であって、
   スレッドごとに用意されたバッファからスレッドの優先度に従って命令をフェッチするフェッチ・ユニットと、
   フェッチされた命令をデコードするデコード・ユニットと、
   デコードされた命令をディスパッチするディスパッチ・ユニットと、
   ディスパッチされた命令を実行し、ストールを検出可能な複数の実行ユニットとを含み、
   前記各実行ユニットは、ストールの検出に応答して実行中の命令（以下、「第１命令」という）がデータ依存する他の命令（以下、「第２命令」という）をそのデータ依存性から特定して記録し、
   前記フェッチ・ユニットは、フェッチした命令が記録された第２命令であるか否かを判定し、第２命令であるとの判定に応答して、次に前記第１命令をフェッチするまでに実行中のスレッドの切り替え行う、
   ストール削減装置。
10. 命令と該命令が使用する前記プロセッサのリソース情報とのペアが各命令の実行時にインオーダー順に登録されるテーブルを更に含み、
    前記各実行ユニットは、前記第１命令が使用する前記コンピュータのリソース情報をキーとして前記第１命令よりも先に前記テーブルに登録されたエントリに対して検索を行うことにより前記第２命令を特定する、請求項９に記載のストール削減装置。
11. 前記第２命令の記録は、所定のテーブルにそのアドレスを保存すること、若しくは命令キャッシュラインの１ビットを利用すること、又はそれらの組み合わせによりなされる、請求項１０に記載のストール削減装置。
12. 実行結果を所定の記憶領域に書き込むリタイア・ユニットを更に含み、
    前記第２命令の記録は、前記第２命令に対する前記リタイア・ユニットによる処理が正常終了することを条件としてなされる、請求項１１に記載のストール削減装置。
13. 前記フェッチ・ユニットは、前記実行中のスレッドのバッファからフェッチした命令が、記録された前記第２命令に一致することに応答して、フェッチすべきバッファを、実行準備が整っている他のスレッドのバッファに切り替える、請求項１２に記載のストール削減装置。
14. 前記フェッチ・ユニットは、前記実行中のスレッドのバッファからフェッチした命令が、記録された前記第２命令に一致することに応答して、前記実行中のスレッドの優先度引き下げを指示する命令を挿入する、請求項１２に記載のストール削減装置。

Images