JP4823075B2 - 最適化コードの自動発生システム - Google Patents

Description

本発明は、少なくとも１つのプロセッサを備えた所定のハードウェア・プラットフォーム上で実行するのに適し、所定の分野のアプリケーションに用いる、ユーザーの提供するソースコードからの最適化コードの自動発生システムに関するものである。この場合、そのようなユーザーは広義に解釈され、エンド・ユーザーだけでなくアプリケーションのプログラマーやシステム・プログラマーをも含む。

コンピュータ使用の当初から、多くの研究がコンパイラに関して行われた。

コンパイラの原理は高級言語で書かれたソースコードを分析し、次いで対象機械のためのそのバイナリコードの均等物を生成することである。一般にこのプロセスは実行に先立って静的に行われる。実行が行われている間に最後の瞬間にコードを生成することを可能にすることにより静的制約を取り除くことを可能にする、ダイナミック・コンパイレーション技術を実装するインタープリータも存在する。

コンパイラは一連のプログラム生産における１つの要素である。コンパイレーションの結果は既にコンパイルされた手順に関連させ、生成させる（別々にコンパイルするか、またはライブラリから取得する）ことが可能であり、それらはローディングの際に静的に、または実行の際に動的にリンクされる。

コンパイラは一般に３つのステージ（段階）で組織される。
１）中間コード生成：ソースコードから出発して、コンパイラはパターンを一致させてソース言語から独立した、一般に中間言語と呼ばれる抽象形態を生成する。この言語は対象機械から独立している。
２）高度最適化：このステージでは、一般に対象アーキテクチャから独立している種々の最適化を組み合わせる：定数の伝搬、力の低下、共通表現．．．。これらの最適化は一般に単一の計測技術（ｍｅｔｒｉｃｓ）に対応する：命令の数を低減、コードの構造を単純化。
３）コード生成および低度の最適化：このステージの間に、対象機械に特異的な操作と最適化のすべてを行う：命令を生成および選択し、レジスタを割当て、命令を順序付ける等。

コンパイラの品質は対象アーキテクチャ（生成されるコードのパフォーマンス）だけでなくソース言語（コンパイルが難しいまたは容易）と関係し、ソフトウェアとしての特性（堅牢性、豊富な選択肢、実行速度等）にも関係する。

動的コンパイルの特殊なケースを除けば、上記ステージの３つをすべて実行前に行う必要があり、これは相応の時間内に行われる必要が有り、それによりコンパイラに実装することができる最適化アルゴリズムの複雑さをそれに応じて制限している。

コンパイラの研究の大部分は、従って、最初、高度ソース言語を選択し、定義することに関係している。

コンパイラの発展もプロセッサのアーキテクチャの発展、そしてさらに詳しくはそのようなアーキテクチャの挙動を記載するパフォーマンスモデルに関係する。すべての最適化問題におけると同様に、主な困難は実行時間を表す費用関数を決定することにある。

最初の命令セットは非常に単純な挙動のものであった：一連の命令の実行時間はシーケンス中の命令のそれぞれの実行時間の合計としてまったく単純に得ることができた。従って、最適化のプロセスは非常に簡単であり、主な最適化戦略は生成される命令の数と複雑さを減らすことからなっていた。

第１の複数命令セットコンピュータ（複数）（ＣＩＳＣｓ）の出現によりある特定の非常に複雑な命令が利用可能である限り少し状況が変化した。そこで、最適化の問題は本質的にパターン一致の問題になった。このカテゴリーもベクトル命令セットおよびベクトルコードを生成するのに直接役に立つループを認識することができるベクトライザを備える。必要に応じて、ソースコードも変形してベクトルコード構造を明かにすることが可能である。

パイプラインの到来により最適化戦略に断絶が生じ、アーキテクチャ開発は命令の処理を、向上の組立ラインにおけるように、順次実行される複数の操作に細分割することになった。この技術は複数の命令の実行を所定の瞬間に重ね合わせることを可能にし、それにより顕著にシステムのパフォーマンスを改善したが、パイプライン「中断（ｂｒｅａｋｉｎｇ）」の場合に、例えば分岐命令の存在によって、顕著な偏差が生じた。この技術はまた所与のコード断片の挙動が予測可能であることに終わりをもたらした。他の主な断絶はメモリ階層の使用に由来するものであった：従って、最適化は非常に特殊な指標：局地性（空間および時間における）に基づくことが必要となった。それにもかかわらず、プロセッサとメモリシステムの間の相互作用が単純であるので、最適化プロセスはミスの数の最小化を主な目的とするものであった。これはミスごとに実行時間のペナルティーが課せられるからである。それでもなお、ミスの数を最小限にすることは困難であり、本質的にループ型の単純なコード構造に対して行うことができるものであると観るべきである。局所性の静的評価がこのように困難であるので、管理プロフィルによる最適化方法が使用されるようになった：すなわち、コードを最初に実行して局所性を精密に決定（してプロフィルを構築）する。次いで、このプロフィルを第２の回において使用して局所性の利用に関連する最適化を実行する。アーキテクチャの複雑さのこのレベルでは、最適化の有効な戦略を簡単に定義することが非常に難しい。より正確には、種々の異なる最適化をどのように組み合わせればよいかが、非常に簡単な状況についてさえ、すでに非常に困難であった：もはやパフォーマンスをモデル化またはそれを効果的に考慮するのに適したメカニズムが存在しなかった。反復コンパイル技術が開発されたのはこの文脈においてであり、実行および最適化を組み合わせて最善のコードを生成するものであった。さらに詳しくは、反復コンパイルはコード変形用ループを実行し、次いでそのパフォーマンスを（静的または動的に）測定することからなる。これらの技術は本質的に最良の解法を与える解法を保存する目的の最小コストコード変換のスペースを探索することからなる。そのような反復方法の計算時間および開発時間におけるコストが非常に高いため、その応用分野は最適化ライブラリに限定されていた。

縮小命令セットコンピュータ（ＲＩＳＣ）アーキテクチャは（ＣＩＳＣと対照的に）単純かつ一様な命令のセットを利用するものであるが、８０年代の中頃に利用可能になった。第１世代のＲＩＳＣプロセッサはその機能性が非常に限定されており、従って、生成されたコートの品質（特に命令の順序付け）がパフォーマンス競争の重要なファクタとなった。ほとんど同様に、非常に長い命令語（ＶＬＩＷ）アーキテクチャハードウェアを利用するために全く同様のコンパイル技術を利用した。ＲＩＳＣおよびＶＬＩＷアーキテクチャは常に単純なパフォーマンスモデルを有しており、このパフォーマンスモデルは全体的に、命令が生成されたプログラムコードと同じ順序で実行される点で決定性であり、それによりそれらのアーキテクチャの挙動をかなり単純化し、従って最適化プロセスを単純化している。それでもなお、それらのアーキテクチャは、よりよいパフォーマンスを得るために、非常に迅速にパイプラインとメモリキャッシュの使用を一般化した（より正確には、これにより平均パフォーマンスを改善したが、予測性を損ねた）。

スーパースケーラー（ｓｕｐｅｒｓｃａｌｅｒ）アーキテクチャ（周期毎に複数の命令を実行する能力を有する）と、就中、命令処理のための順不同処理メカニズムとの出現によりパフォーマンス最適化のプロセスがさらに困難なものになった。さらに、メモリ階層が急速に発展した：レベル数が増加し、就中種々のキャッシュ（先行載荷（ｐｒｅｌｏａｄｉｎｇ）、優先度管理（ｐｒｉｏｒｉｔｙ ｍａｎａｇｅｍｅｎｔ）、．．．）を多かれ少なかれ明示的に管理するのに役立つ種々のメカニズムが出現している。これらのメカニズムが一緒になったために、非常に単純（２つまたは３つの表へのアクセスをとるループ）である場合でさえも、コード断片の挙動は予測することが非常に難しくなり、そのため単純なパフォーマンスモデルに基づいて最適化するのは不可能になった。この状況はプロセッサのパフォーマンスとメモリのパフォーマンスとの差により単に悪化している。

総じて、最近２０年にわたって、プロセッサのアーキテクチャにおいて能力に関してはかなり豊かになった。このように、レジスタの数はかなり増加した：すなわち、ＣＩＳＣアーキテクチャで標準であった８レジスタからＲＩＳＣは３２レジスタに移行し、スーパースケーラー・アーキテクチャは８０レジスタに移行した。一見したところでは、レジスタの数を増加すると最適化が簡単になると考えられる。実際は、メモリが発展したのでレジスタの使用がさらに重要になり、このレジスタの割り当ての問題について効果的レジスタ割当アルゴリズムのコストがかなり増加している。これは複雑さが利用可能なレジスタの数の指数関数であるためである。

これら最近の開発に応じて、コンパイラ技術はほとんど変化しなかった：すなわち、実装された最適化の数が増加したが、全体的最適化戦略を定義する能力は進化しておらず、低下さえしている。

最後に、最近の傾向は「動的」コンパイルを指向している。原理は単純かつ魅力的である：動的コンパイル（または実行に特化）はコードを最後の瞬間、すなわち実行時に最適化することからなる。コードシーケンスが、プログラムの入力データ（実行コンテクスト）の関数として適合される（「特化される」）。実行時、あるメカニズムがプログラムの挙動を命令のシーケンスが実行される頻度の関数として「検査（ｅｘａｍｉｎｅｓ）」し、特定の実行コンテクスト用に最適化されたバージョンを実装するか否か決定する。このタイプの本質的動的メカニズムはそれ自身の自走のための計算時間の面で安価な最適化技術に限定される。その理由は最適化技術は最適化するはずのコードの実行に不利益をもたらしてはならないからである。

ライブラリはフィールドまたはそのようなフィールドの一部分を表す一組の手順である：すなわち、ライブラリのコンポーネントは標準的でありかつ頻繁に使用される手順に対応するものであることが必要である。ライブラリの概念は非常に古く、コンパイラの概念よりも古く、ライブラリはソフトウェア工学の主要な柱の１つである（コンポーネントの再使用）。特に、ジャバ（Ｊａｖａ（登録商標））はライブラリの概念を非常に系統的に利用する言語の一例である。

ライブラリは最も簡単なものから最も複雑なものまでの異なる抽象化レベルに対応することができる：すなわち、ＢＬＡＳ１（“ｂａｓｉｃ ｌｉｎｅａｒ ａｌｇｅｂｒａ ｓｕｂｒｏｕｔｉｎｅｓ ｌｅｖｅｌ １”、基礎線形代数ルーチンレベル１）はベクトルに関する一組の非常に単純な操作であるが、多数の従来の線形代数アルゴリズムを表現することが可能である。他の極端な例としては、ＬＩＮＰＡＣＫおよびＥＩＳＰＡＣＫがあり、これらは線形系および固有値ベクトルおよび／または固有値をそれぞれ解く手順の完全なセットである。多数のライブラリが開発され、以下の特定の分野で広く使用されている。
・科学計算：ＢＬＡＳ１、ＢＬＡＳ２、ＢＬＡＳ３、ＢＬＳＴ、ＳＰＡＲＳＥ ＢＬＡＳ、ＬＩＮＰＡＣＫ、ＬＡＰＡＣＫ、ＢＬＡＣＳ、ＰＶＭ、ＭＰＩ、など；
・シグナル処理：ＦＦＴＰＡＣＫ、ＶＳＩＰＩ、など；および
・グラフィックス：ＤｉｒｅｃｔＸ、ＯｐｅｎＧＬ。

一定数のライブラリが所定の応用分野において定義され、特定されるということはその分野が「合成（ｓｙｎｔｈｅｓｉｚｅｄ）」することが可能であることを表している。

それにもかかわらず、ライブラリの最大の欠点はそれらの能力が非常に限定されており、それらはマニュアルの利用を必要とすることである（すなわち、それらはソースコード中に、挿入されるべき手順に対する明示のコールを必要とする）。

第１世代の（小サイズの単純手順に対応する）ライブラリはアセンブラ言語で手動開発されるのが一般的であった。パフォーマンスが主要な基準である場合はいつでもそれが該当した（ただし、当然、手順は合理的なサイズであった場合に限る）。

しかしながら、通常「インライン（ｉｎ−ｌｉｎｅ）」プロセスであるコンパイル（コンパイル時間は控え目でなければならない）とは異なり、ライブラリの最適化は本質的に「オフライン（ｏｆｆ−ｌｉｎｅ）」プロセスであり、計算時間に関してずっと欲張りな方法を利用することができる。このように反復コンパイルはライブラリ開発の優れた最適化ツールであるが、残念ながら、最も単純なコードに使用可能であるに過ぎず、用途が限定される。

同様に、自動同調線形代数ソフトウェア型の技術はある最適化を行う（ブロックサイズのような良好なパラメータを選択する）ことを可能にする。残念ながら、その技術は用途がごく限られているが、その理由は、対象アプリケーションのタイプ（緻密なマトリクスの計算、非常に高度の時間局地性を特徴とする計算）に大きく依存するからである。

パフォーマンスを解析するための現在のツールは非常に変化に富む（特に探索される対象の関数として）：
・パフォーマンス試験（「ベンチマーク（ｂｅｎｃｈｍａｒｋｓ）」）：これらは応用分野を多かれ少なかれ表し、種々の機械のパフォーマンスを比較することを可能にするコードである。
・シミュレータ：これらはアーキテクチャの挙動が最終レベルで理解されることを可能にする。残念ながら、それらは非常に高価であり、開発が難しく、非常に低速であり、対象プロセッサを必ずしも正確に表すものではない。
・演算モデル：アイデアとしては、機械のパフォーマンスを等式の形にすることである。一般に、それらの用途は極端に限定され、それらは非常に単純なコードの同じものの周りの種々の単純な変異体（バリアント）を検討するためにのみ有効である。
・プロフィルを監視および／または管理するツール：これらのツールは、プログラムの実行に関する異なる種類の情報を（特化されたハードウェアを有するコンピュータを用いることにより）回復する役割を持ち、ここでそのような情報はサイクルの数、ミスの数などに関係する。

以下の所見を述べることができる：
・パフォーマンステストはほとんど発展しておらず、就中、それらは大き過ぎる商業上の利害関係の主題になっている。供給元がベンチマーク試験においてよく動作するようにコードを特異的に最適化することがしばしばなされているが、得られた結果の範囲と有効性が紛らわしくなる。
・シミュレータ：対象とするアーキテクチャが非常に複雑になった場合、シミュレータが与える結果を、コードを最適化するために利用することがますます困難になりつつある。
・演算モデル：これらはほとんど発展せず、上述の局所的用途以外にはそれらは使用できない。理由の１つは、良い演算モデル化ツールは挙動が「一様平均」であることに基づいており、実際には真実からかけ離れていることである。
・プロフィルを監視および／または管理するツール：これらは本質的に３つの欠点を有する：それらは全体的であり、作用の経時分布に関連しない情報を与え；それらは細かいレベルでコードと挙動とが相関することを可能にせず；そして、最後にそれらを有効利用することが（シミュレータを用いた場合と同様に）、特に対象アーキテクチャの複雑さの故に、非常に困難である。

本発明は上述の欠点を克服し、少なくとも１つのプロセッサを備える所定のハードウェア・プラットフォームがユーザーにより提供されたソースコードに自動的に動作して、所定の適用分野に対して該プラットフォーム上で動作する最適化コードの生成を可能にすることを目的とする。

さらに詳しくは、本発明は選択されたソース言語から独立してコンピュータシステムのパフォーマンスを向上させること、およびこれを、単純または複雑である命令を利用することが可能であり、多数または少数のレジスタ、機能性ユニットおよびキャッシュレベルを備えていてもよいアーキテクチャのプロセッサを実装するシステムに対して行うことを目的とする。

本発明の他の目的は特化したプログラムのライブラリの機能的範囲の限界を無くすことであり、さらに本発明は種々の複雑さのレベルを示す多数の類似したコード構造に対して最適化されるコードを自動的に生成するシステムを創出することを目的とする。

本発明によれば、これらの目的は、ユーザーにより提供されたソースコードに自動的に動作して、少なくとも１つのプロセッサを有し所定の適用分野おいて使用する所定のハードウェア・プラットフォーム上で動作するのに適した最適化コードを生成するシステムであって、前記システムは前記所定の適用分野について、前記プロセッサの挙動をパフォーマンスで表す、ベンチマークシーケンスと呼ばれる記号コードシーケンスを受領する手段；前記所定のハードウェア・プラットフォーム、そのプロセッサ、および前記ベンチマークシーケンスに基づいて定義された第１の静的パラメータを受領する手段；同じく前記所定のハードウェア・プラットフォーム、そのプロセッサおよび前記ベンチマークシーケンスから定義された動的パラメータを受領する手段；前記ベンチマークシーケンス、前記静的パラメータおよび前記動的パラメータを用いて行われる試験およびパフォーマンスの測定から最適化ルールを作成する分析装置；第一に前記ベンチマークシーケンス、および第二に前記ユーザーソースコードを検査するための最適化ルールを受領するコードを最適化および生成し、最適化可能な複数のループを検出し、前記複数のループをカーネルに分解し、かつコードをアセンブルおよび投入して前記最適化コードを引き渡す装置；およびコードを生成し最適化する前記装置から来る情報を再投入し、かつ前記カーネルを前記ベンチマークシーケンスに戻して関連づける手段を備えたことを特徴とするシステムにより達成される。

さらに詳しくは、前記分析装置は、第一に前記ベンチマークシーケンス受領手段に、第二に前記静的パラメータ受領手段に接続された発生器であって、移送手段により移送されてバリアントデータベースに格納される多数のテストバリアントを自動的に生成するテスト発生器；第一に前記バリアントデータベースに格納された前記テストバリアントを受領する移送手段に、第二に前記動的パラメータを受領する手段に接続された前記テストバリアントを前記動的パラメータの変化の範囲内で実行して移送手段により移送されて結果データベースに格納される結果を生成するエキササイザ；および前記移送手段に接続されて前記結果データベースに格納された前記結果を受領し、それらを分析し、かつそれらから、移送手段により最適化ルールデータベースに移送される最適化ルールを推論するアナライザを備える。

好適には、前記アナライザは最適パフォーマンスに対する任意の閾値を有するフィルタ手段を備え、前記バリアントが前記フィルタ基準を満足する限り、前記結果データベースのバリアントを、前記パラメータ空間において最適であると判定するようにしている。

好適な一実施形態では、前記アナライザは、さらに前記静的パラメータを変更する手段および前記動的パラメータを変更する手段を備える。

前記コードを最適化および生成する装置は、最適化コードを生成する装置と最適化器とを備え、前記最適化器は第一に前記オリジナルソースコード中に特定されたカーネルを受領する手段に、第二に前記ベンチマークシーケンスを受領する手段に、および第三に前記最適化ルールを受領する手段に接続された戦略選択モジュールであって、テストされたベンチマークシーケンスに対応するそれぞれのカーネルについてそれぞれあるパラメータの組合せの下で最適である複数のバージョンを生成する戦略選択モジュールと、前記最適化ルールを受領する手段に、前記戦略選択モジュールから来る情報を受領する手段に、および前記複数のバージョンを受領する手段に接続された組合せ・アセンブルモジュールとを備え、移送手段を介して、前記対応する最適化バージョン、それらの使用帯域、および必要に応じて前記実行されるべきテストを含む情報を引き渡してどのバージョンが最も適しているかを動的に決定するようにしている。

好適な任意的な一実施形態では、前記システムは最適化カーネルデータベースを備え、前記組合せ・アセンブルモジュールは移送手段により前記最適化カーネルデータベースに接続されて前記最適化カーネルデータベースに情報を格納し、前記情報は前記最適化バージョン、それらの使用帯域、および必要に応じて実行されるべきテストを含む情報をどのバージョンがもっとも適しているかを動的に決定するようにしている。

前記コード最適化・生成装置は最適化器と最適化コード生成装置とを備え、前記最適化コード生成装置はユーザーソースコードを受領する手段に接続された最適化可能ループ検出手段、それらをカーネルに分解するモジュール、移送手段を介して前記最適化器に接続されて前記検出されたカーネルのアイデンティティー（識別情報）を伝送するようにした事例分析、アセンブルおよびコード投入モジュール、および前記対応する最適化カーネルを記載する情報を受領する移送手段を備え、前記事例分析、アセンブルおよびコード投入モジュールも最適化コード供給手段に接続されている。

前記事例分析、アセンブルおよびコード投入モジュールも前記最適化カーネルデータベースに接続され、最適化カーネルを記載する情報を、前記検索された最適化カーネルがそこに格納されているならば、前記最適化器を呼び出すことなく、受領するようにしている。

有利な特徴によれば、前記事例分析、アセンブルおよびコード投入モジュールは、さらに、前記ベンチマークシーケンスに前記事例分析、アセンブルおよびコード投入モジュールにおいて発見されたカーネルを、前記最適化カーネルデータベースまたはベンチマークシーケンスのいずれにも対応するアイデンティティーを持たずに追加する手段を備える。

一つの特定の実施形態では、前記システムはコンパイラとリンクエディタとを備え、再組織化されたソースコードを前記コード最適化・生成装置から受領し、前記ハードウェア・プラットフォームに適合された最適化バイナリコードを生成するようにしている。

前記システムは、前記最適化カーネル用の前記ソースコードを前記最適化カーネルデータベースから前記コンパイラに移送する手段を備えていてもよい。

他の変形実施形態では、前記システムはコンパイラと、動的ライブラリを前記ハードウェア・プラットフォーム上にインストールするインストールモジュールを備え、前記ライブラリは前記最適化カーネルの能力の全てを含むようにすることも可能である。

本発明は種々の応用分野、特に科学計算、信号処理、およびグラフィックス処理に適用することができる。

一つの特定の特徴に従えば、前記ベンチマークシーケンスは、ソース型言語で特定され、かつループ本体用のコードの複雑さの昇順により階層レベルで組織化された一組の単純かつ包括的ループ型コード断片を含む。

必要に応じ、前記ベンチマークシーケンスは、唯一の個別動作がテストされ、高さ０のツリーによって表される単一の演算式により構成されるループ本体に対応するレベル０のベンチマークシーケンスを含む。

さらに、前記ベンチマークシーケンスは、レベル２のベンチマークシーケンスを含んでいてもよく、前記ベンチマークシーケンスに対しては、２つのレベル０の操作の組合せ；および高さ１のツリーによって表される単一の演算式により、またはそれぞれ高さ０のツリーによって表される２つの演算式により構成されるループ本体に対応するレベル１のベンチマークシーケンス操作が考えられ、かつテストされる。

一つの考え得る実施形態では、前記ベンチマークシーケンスはレベル１のベンチマークシーケンスを含み、前記ベンチマークシーケンスに対して２つのレベル１の操作または３つのレベル０の操作が考えられ、かつテストされる。

前記静的パラメータは、特に各ベンチマークシーケンスのループ反復数、表アクセス間隔（ｓｔｅｐ ｓｉｚｅ）、およびオペランド型、使用命令の型、プリロード戦略、および命令および反復の順序づけ戦略を含む。

前記動的パラメータは、特にメモリ階層の種々のレベルにおける表オペランドの位置、表開始アドレスの相対的位置、および分岐履歴を含む。

好適には、前記最適化カーネルデータベースは、現実の有用な、複雑さの昇順に階層レベルに組織化されたコード断片に対応するループ型ソースコードシーケンスを含む。

前記所定のハードウェア・プラットフォームは、例えば、インテル社から供給された、いわゆるイタニウム（Ｉｔａｎｉｕｍ^TM）型の少なくとも１つのプロセッサ、またはＩＢＭ社から供給されたパワー（Ｐｏｗｅｒ）またはパワーＰＣ（Ｐｏｗｅｒ ＰＣ^TM）型の少なくとも１つのプロセッサを備えることができる。

前記イタニウム（Ｉｔａｎｉｕｍ^TM）型のプロセッサを有するシステムに特に適用可能な一つの考え得る実施形態では、前記最適化ルールは下記のルールのうち、少なくとも幾つかを含む：
ａ）書込パフォーマンスが読取パフォーマンスに比べて劣っている場合、書込の数を最小化する；
ｂ）浮動小数点におけるローディングペアの使用の重要性；
ｃ）ループがループ本体の複雑さの関数として展開される程度を調整する；
ｄ）演算操作における操作待ち時間を用いる；
ｅ）短いベクトルに対してマスキング技術を使用する；
ｆ）メモリアクセス（読取、書込、プリローディング）用の局所サフィックスを用いる；
ｇ）プリローディング距離を定義する；
ｈ）程度４のベクトル化を実行してＬ２バンクの衝突の若干を回避する；
ｉ）複数のバリアントを考慮に入れて他のＬ２バンクの衝突と、読取／書込キーにおける衝突とを回避する；
ｊ）種々の最適化に関連するパフォーマンス改善を考慮に入れる；
ｋ）誤った予測（短いベクトル）を最小化する分岐鎖を用いる；
ｌ）メモリアクセスを統合する（ピクセルを一緒のグループにする）；および
ｍ）ピクセルにベクトル化処理をする。

さらに詳しくはパワー（Ｐｏｗｅｒ）またはパワーＰＣ（Ｐｏｗｅｒ ＰＣ^TM）型のプロセッサを含むシステムに適用可能な他の考え得る実施形態において、前記最適化ルールは下記のルールの少なくともいくつかを備える：
ａ）読取値を再順序づけしてキャッシュ欠陥をまとめる；
ｂ）書込値に対してのみプリローディングを用いる；
ｃ）ループがループ本体の複雑さの関数として展開される程度を調整する；
ｄ）演算操作における操作待ち時間を用いる；
ｅ）メモリアクセス（読取、書込、プリローディング）用の局所サフィックスを用いる；
ｆ）プリローディング距離を定義する；
ｇ）複数バリアントを考慮に入れて読取／書込キーにおける衝突を避ける；および
ｈ）種々の最適化に関連するパフォーマンス改善を考慮に入れる。

本発明の他の特徴および利点は、点封図面を参照した特定の実施形態の下記の説明から明らかである。

まず、図１を参照すると、図１は、最適化コードを自動的に生成してコード最適化・生成モジュール８０の出力７３を介して、少なくとも１つのプロセッサ９１を備える所定のハードウェア・プラットフォーム９０上で実行するのに適した最適化コードを供給するシステム全体を示す。

前記コード最適化・生成システムは所定の適用分野に適合され、モジュール８０の入力端７１を介して、ユーザーにより提供されたソースコード１７を受領する。ここで、「ユーザー」という用語は広くエンド・ユーザーだけでなく、アプリケーションのプログラマーおよびシステムのプログラマーをも包含するものと理解されるべきである。

問題の適用分野についてのパフォーマンスとしてプロセッサ９１の挙動を表す、ベンチマークシーケンス１と呼ばれる記号コードシーケンスはコード最適化・生成モジュール８０の入力端５２およびアナライザモジュール１０の入力端５１に適用される。

種々の環境パラメータおよびベンチマークシーケンス同士の間の相互作用の効果を分析することにより、パフォーマンスの良好な帯域および劣悪な帯域を配置し、それらが良好および劣悪である理由を理解することが可能である。ベンチマークシーケンスシーケンスは必ずしも従来のプログラミング言語により生成された現実のコードシーケンスを表さない。テストされたベンチマークシーケンスの部分集合のみがユーザーコードの最適化に使用されるカーネルに対応する。

最適化可能なループは変数ベクトルについて多かれ少なかれ複雑な操作のアルゴリズム表現をコードするプログラム構造である。

カーネルまたは基本ループは単純な形の最適化可能なループを構成する。本発明のシステムのモジュール８０は自動的に最適化されたカーネルを特化された演算ライブラリにおいて利用可能にされた機能の数よりもはるかに大きい数で生成することを可能にする。一般に、所与のカーネルのいくつかのバージョンを生成することが可能であり、それぞれのバージョンは環境パラメータのある組合せについて最適化されている。

最適化器１２（図３）における最適化ステージは従って適用分野の代表である能力を表す対象プラットフォーム９０について最適化されているカーネルの一組、すなわちライブラリを自動的に生成することからなる。

最適化ステージは、ユーザー・プログラムからのソースコードを検査してその中に最適化可能なループを検出し、標準的コンパイラにより生成されたであろうコードの代わりに最適化されたカーネルの使用を強制するようにしたコード生成器１８（図３）におけるコード生成ステージに関連している。

モジュール８０から来る情報をベンチマークシーケンス１に再投入する手段７４が用意される。

アナライザモジュール１０における分析ステージが前記コードの最適化および生成ステージに先行し、前記分析ステージは、対象ハードウェア・プラットフォーム９０および考慮されている適用分野について、コンパイルされるべき最適化ルールを決定する役割を果たし、最適パフォーマンスが得られるようにしている。アナライザモジュール５７からの出力５７は最適化ルールを最適化ルールデータベース９に移送する役割を果たしているが、それ自体は移送手段５９を介してモジュール８０の最適化器１２に接続されている。

前記アナライザモジュール１０は図２を参照して以下にさらに詳細に説明する。

前記アナライザモジュール１０は、手段５３および５４を介して、プロセッサ９１、およびより一般的には最適化のための対象プラットフォーム９０が基礎を置くシステムのアーキテクチャの関数として、そしてまたベンチマークシーケンスの関数として特定される静的パラメータ２および動的パラメータ７を受領する。

特に、静的パラメータ２は各ベンチマークシーケンスについてのループ反復数、表アクセス間隔、およびオペランドの型、使用命令の型、プリローディング戦略、並びに命令および反復の順序づけ戦略を含んでいてもよい。

特に、前記動的パラメータ７は、メモリ階層の種々のレベルにおける表オペランド配置、表開始アドレスの相対位置および分岐履歴を含んでいてもよい。

パフォーマンスアナライザモジュール１０において、テスト発生器３は静的パラメータ２および動的パラメータ７に関係するデータを利用するが、これらパラメータは入力５１および５３によりそこに供給され、移送手段６１によりバリアントデータベースに移送される潜在的に非常に多数のバリアントを生成するようにしている。

エキササイザと呼ばれる他の自動ツール５はバリアントデータとバリアントデータベース４を移送手段６２を介して受領し、このようにして作成されたテストを実行し、それらを実行する一方、変化の範囲にわたって移送手段５５により供給される動的パラメータ７を変え、移送手段６３を介して関係する測定値を結果データベースと呼ばれるもう一つのデータベース６に移送する。

結果データベース６に格納された測定値はそれ自体移送手段６４によりアナライザ８に移送され、アナライザ８は、パフォーマンスの良好な帯域および劣悪な帯域を特定することにより、移送手段５７により最適化ルールデータベース９に移送される最適化ルール９を作成する役割を果たす。

前記アナライザ８はまた、例えばアナライザ８が所与のパラメータにおける変化に対する感度が小さいことを見いだした場合は、静的パラメータ２を変更する手段５４と動的に変更する手段５６を有する。

アナライザ８は最適パフォーマンスの任意の閾値におけるフィルタ手段を含んでいてもよい。そのような場合、最適パフォーマンスに対応しない結果データベースのバリアントを、該バリアントがフィルタ基準を満足する限り、それでもなおパラメータ空間内に最適であるとして保持することが可能である。

コード最適化・生成モジュール８０を以下に図３を参照して説明する。

最適化装置１２は、コード生成モジュール１８にオリジナルソースコード中に特定されるカーネルを受領する手段９２により接続された戦略を選択する手段１３を含む。戦略選択モジュール１３はベンチマークシーケンス１を受領する手段５２および最適化ルール９を受領する手段５８にも接続される。戦略選択モジュール１３は出力６７において、テストされたベンチマークシーケンスに対応するそれぞれのカーネルについて、それぞれパラメータのある組合せについて最適であるｎ個のバージョンのセットを生成する。

バージョンを組合せ・アセンブルするモジュール１４は最適化ルール９を受領する手段５９、戦略選択モジュール１３から来る情報を受領する手段６６、および複数１５のバージョン１〜ｎを受領する手段６８に接続される。モジュール１４は移送手段９３を介して情報を引き渡し、前記情報は対応する最適化バージョン、それらの利用帯域および必要に応じ、実行されるべきテストを含み、どのバージョンが最も適しているかを動的に決定するようにしている。

最適化コードを生成する手段１８はユーザーソースコード１７を受領する手段７１に接続される最適化ループ検出モジュール２０を備える。モジュール２０の出力７５はカーネルに分解する手段２２に接続され、出力７７自体は事例分析・アセンブル・コード投入モジュール２３に接続されており、このモジュール２３は移送手段９２を介して最適化器１２に接続され、検出されたカーネルのアイデンティティーを伝送するようにしている。モジュール２３は、また、移送手段９３を介して対応する最適化カーネルを記載する情報を受領する。モジュール２３は、また、最適化コード１９を供給する手段７３に接続される。

好適な一実施形態では、コード最適化・生成モジュール８０は最適化カーネルのデータベース１６を含む。組合せ・アセンブルモジュール１４は最適化カーネルデータベース１４に移送手段７９により接続され前記データベース：すなわち、最適化カーネルに、最適化バージョン、それらの利用帯域、および必要に応じて実行されるべきテストを含む情報を格納してどのバージョンが最も適しているかを動的に設定するようにしている。このバリアントでは、事例分析・アセンブル・コード投入モジュール２３は、また、最適化カーネルデータベース１６に移送手段７２を介して接続され、探索されたカーネルが既に前記データベース１６に格納されているならば、最適化カーネルを記載する情報を、最適化器１２を呼び出すことなく受領するようにしている。

図３から分かるように、事例分析・アセンブル・コード投入モジュール２３は、さらに、ベンチマークシーケンス１に前記モジュール２３に見いだされたカーネルを、最適化カーネルデータベース１６またはベンチマークシーケンス中の対応するアイデンティティーを有しなくても、追加する手段７４を備える。

図４は、最適化器１２が、最適化カーネルデータベース１６が存在する図３に示すバリアントと同じであるので、最適化器１２が示されていない特定の実施形態を示す。

この実施形態では、コード生成モジュール１８は事例分析・アセンブル・コード投入モジュール２３の出力７３において再組織化されたソースコード１９を生成し、このコード１９は引き続き従来のプログラム作成ツール８１、８２により処理され、対象プラットフォーム９０について最適化されたバイナリコード８３が得られるようにしている。

図４は非常に容易に実装される実施形態を示す。オリジナル・ユーザー・ソースコード１７は上述のコード最適化・生成モジュール８０内で、その最適化ループがサブプログラムへの呼び出しにより置き替えられ、サブプログラムに対応するコードが再組織化されたソースコード１９に最適化されたカーネルデータベース１６から投入されるようにして再組織化される。このようにして再組織化されたソースコード１９は、その結果、コンパイラ８１とリンクエディタ８２を含む従来の連鎖を通る際に、ハードウェア・プラットフォーム９０に適合された最適化バイナリコード８３を生成するのに必要とされるすべてを含む。

一つの考え得るバリアントでは、最適化カーネルデータベース１６の最適化カーネルのソースコードは追加のソースライブラリとして直接コンパイルステップにおいて使用することができる。これは図４において最適化カーネルデータベース１６をコンパイラ８１に接続する破線矢印８５により示されている。このバリアントは、従って、最適化カーネルのソースコードを再組織化されたソースコードに直接投入することを回避するのに役立ち、モジュール１８内の生成工程を実行し易くしている。

図５は図４に示す実施形態のバリアントとなる実施形態を示す。

図５のバリアントはある操作システムにより提供される能力を利用し、それにより実行時に編集する動的リンクによりプログラムにアクセス可能である実行可能なバイナリコードの形でライブラリをインストールすることが可能である。

図５のバリアントでは、最適化データベース１６からコードを再組織化されたソースコード１９に投入する必要がなくなる。しかしながら、最適化されたカーネルの能力をすべて含む動的ライブラリをコンパイラ１８１およびインストールモジュール１８２を介して対象プラットフォーム９０にインストールすることが必要である。単一のコンパイラを図５のコンパイラ８１および１８１共通に使用することが可能である。図５のこのバリアントでは、インストール操作は各対象プラットフォームについて１回だけ必要とされ、このバリアント最適化プロセスの全体的処理の点でより経済的である。

本発明の最適化コード生成システムは科学計算；信号処理；およびグラフィックス処理の３つの分野への適用に特に好適である。

これら３つの領域において使用されるコードは実装に重要な種々の特性ＣＨＡＲ１〜ＣＨＡＲ４を示す。
・ＣＨＡＲ１：最大量の実行時間を消費するコード部分を構成するループ型構造（または「入れ子ループ」）を示す。
・ＣＨＡＲ２：使用されるデータ構造はほとんど多次元表型であり、非常に規則的なパターン（行、列、ブロック、など）でアクセスされる。
・ＣＨＡＲ３：ループ（または入れ子ループ）は一般に独立の反復により構成され並行して実行することが可能である。
・ＣＨＡＲ４：ループ本体は一般に一連の演算式によって表現構成され、多量のデータにわたって一様（または準一様）である計算に対応する。

当然、科学計算、信号処理およびグラフィックス処理のこれら３つの分野には共通点があるものの、それらには大きな相違点もある。従って、信号処理の分野では、複素数型のデータは特異的な最適化を必要とする非常に重要なタイプのデータを構成するが、このタイプのデータの重要性は他の２つの分野においては取るに足らない。グラフィックス処理は一つの特定の型、すなわちピクセルのデータ、および特別な計算を使用することにより非常に際立っている。さらに、グラフィックスでは、次元ストリームに関係するデータ構造およびアルゴリズムが基本的に重要である。

上述の４つの特性（ＣＨＡＲ１〜ＣＨＡＲ４）はコード最適化に非常に強力であり、それらは完全に特殊な木靴を開発することを可能にする。
・ＣＨＡＲ１⇒最適化は２つの主な利点：反復可能性（および予測可能性）および表現の緻密さを示すループ型構造に集中する。
・ＣＨＡＲ２⇒実行時間の大きな部分（または実際キャッシュメモリの使用が増えると主要部分）を代表する表へのアクセスは、規則性があるので、容易に分析し最適化することができる。
・ＣＨＡＲ３⇒ループ内および入れ子ループ内の相互作用から独立しているので、表へのアクセスの関数として反復空間を通る（最適化）経路を、対象アーキテクチャに特異的な特性に依存するように、使用することが可能になる。表のＮ個の所与のエレメントにアクセスすることはＮ！（Ｎの階乗）通りの異なる仕方（順序）で実行することが可能である。
・ＣＨＡＲ４⇒ループ本体が演算式として単純な構造をしているので、演算式の３つの代表に基づいて系統だった階層的なアプローチを用いることが可能になる。

分析ステージは本質的に実験的なステージであり、その終点で下記が必要である；
・アーキテクチャの強い点および弱い点を決定しておくこと；
・パフォーマンスおよびコード構造の相関のさせ方を知ること；および
・コードに関連する種々のパラメータの関数であってもよい、良好な最適化戦略を突き止めておくこと。

既に述べたように、出発点は、単純であるが包括的であり、かつ「ベンチマークシーケンス」と呼ばれる一組の「ソース型」コード断片である。これらのコード断片はループ型構造をしており、「ソース型」という用語は操作が高いレベルで特異化されており、アセンブラのレベルではないことを意味する。

これらのコード断片はループ本体において下記のように、コードの複雑さの昇順で階層レベルに組織化荒れている：
・レベル０ベンチマークシーケンス：このレベルでは、単一の個別操作がテストされる。すなわち、ループ本体は１つの操作ｌ：すなわち、表からエレメントを読み取る、表にエレメントを書き込む、浮動少数点加算などを含む。これらの操作は高さ０のツリーにより表される単一の演算式により構成されるループ本体に対応する。
・レベル１ベンチマークシーケンス：このレベルでは、２つのレベル０操作が考慮されテストされる：表から読取り表へ書き込む、２つの異なる表から読み取る、表において読取および追加するなど。これらの操作は高さ１のツリーにより表される単一の演算式、または２つの演算式であってそれぞれ高さ０のツリーにより表されるもののいずれかにより構成されるループ本体に対応する。
・レベル２ベンチマークシーケンス：このレベルでは、２つのレベル１操作または３つのレベル０操作が考慮され、テストされる：３つの異なる表から読み取る、２つの表からコンポーネントごとに読み取る、結果を第３の表に書き込むなど。
・レベルＫベンチマークシーケンス：レベルＫは、先行するレベルから再帰すること（ｒｅｃｕｒｒｅｎｃｅ）により容易に定義することができる。

レベル０のベンチマークシーケンスのすべてが「人為的」、すなわち「現実の」ループを表さないコード断片に対応する。

このように複雑さの昇順のレベルに組織化することも最適化ステージにおいて用いられる。

このようにして定義されるベンチマークシーケンスのセットは無限である。

これらのベンチマークシーケンスは２つの異なるクラスのパラメータを用いる。：
・静的パラメータ：これらのパラメータは静的に（すなわち、実行に先立って、かつ実行とは独立して）定義される。これらの静的パラメータはそれ自体２つの主要なサブクラスに細分割される：すなわち、高レベル静的パラメータ（ループ反復数、表アクセス間隔、オペランド型、．．．）、および低レベル静的パラメータ（特異的命令、命令順序づけなどの使用）。
・動的パラメータ：これらのパラメータはループを実行する間に定義される。例えば、それらは下記からなる：表オペランドの配置、表出発アドレスの相対的位置、．．．。

これら２つのクラスのパラメータは非常に異なる態様で用いられる：静的パラメータは異なるテストコード断片を以下に説明するバリアントおよび／または最適化と組み合わせて用いられるが、動的パラメータは単独でテストベンチ上での実行の際に用いられる。

高レベル静的パラメータは比較的に限定され、高レベル言語（例えば、フォートランまたはＣ）で表現されたループおよび表の従来のパラメータに本質的に対応するが、対象プロセッサに関係する特異性はない。

低レベル静的パラメータによりプロセッサ（アーキテクチャ）と関連する、および命令（オブジェクトコード発生器）の順序付けと関連する特異性のすべてを考慮に入れることが可能になる。ベンチマークシーケンスは（ソース言語で定義され、かつ意図されたプロセッサとは独立の）高レベルの抽象化であり、特にそれらは最適化を含まない。それらを所与のプロセッサ上でテストするために、対応するアセンブラコード断片を生成し最適化する必要がある。この生成の際に、いくつかのバリアント（アセンブラ命令シーケンス）が自動的に生成される。同じベンチマークシーケンスと関連するバリアントのすべてが当初のベンチマークシーケンスに意味的に同等であるコード断片である。異なるコード最適化技法に（すなわち、低レベル静的パラメータに）対応する。これらの最適化は抽象的にベンチマークシーケンスの特定の構造を参照することなく定義することができ、それらは低レベル静的パラメータの主要部分を構成する。

低レベル静的パラメータは下記を含む：
・アセンブラ命令を用いること：ソースレベルにおける単一操作は種々の命令シーケンスを用いて実装することが可能である。特に、この時点においてデータおよび命令のプリローディングを用いる種々の考え得る戦略を取り扱うことが必要である；
・ループ本体の構造：ループの本体を（異なる程度に）展開する；ループ本体の順序づけ命令（プリローディング距離、ベクトル化、キャッシュミスをまとめること、キー間の処理衝突）；および
・反復の順序づけ：異なる深さのソフトウェア・パイプライン。

多くにコンパイラにおいて、上記低レベル静的パラメータはコンパイル時間選択肢に対応し、意図する最適化を明示的に実装するのに役立つ。

テスト発生器３の役割は、第一に高レベル静的パラメータ（例えば表アクセス間隔）に、また低レベル静的パラメータに対応する、上記の種々のバリアントを生成することである。

レベル１ベンチマークシーケンスに対して、生成および分析すべきバリアントの総数は非常に多く、数百万にカウントされることがある。それにもかかわらず、生成および分析プロセスは非常に単純に自動化することができる。

エキササイザ５およびアナライザ８では、目的は種々のバリアントのパフォーマンスをテストし、できるだけ良いバリアントおよび／または最適化を選択することである。

このステージは多数の結果の生成を含み、これらの結果は結果データベース６に格納される。実験は階層的に分析ステージと組み合わせて実行される：従って、最初の実験はレベル０ベンチマークシーケンスのバリアントに実行される。この第１キャンペーンの実験の終点で、種々のバリアントについて得られた結果の関数としてソートを実行することができる。若干のバリアントはこのように直接除外され、下記のレベルの考察において考慮されない。これにより、実行することが必要である実験の数の組合せによる爆発的増加を制限することが可能になる。

結果を分析するステージは一見すると、唯一の指標（パフォーマンス）が用いられているので、実行するのが非常に簡単である。実際、プロセスの複雑さの第部分は、一般に最良のバリアントの選択がパラメータに非常に強く依存していることに由来する。

第１のソートを各ベンチマークシーケンスについて最適パフォーマンスをアーキテクチャの仕様に基づいて計算することにより非常に簡単に実行することができる。残念ながら、アーキテクチャとコードの間（レベル０およびレベル１ベンチマークシーケンスと同様に単純なコード断片を含む）の複雑な相互作用に関連してすぐ困難が生じる：これによりパラメータの関数としてのパフォーマンスの変化を記載する図が複雑になる。そのような複雑な挙動を最初に画像処理アルゴリズムを用いることにより分析することができ、次いで所与のバリアントをあるパラメータ範囲に適格とすることにより合成する。このように、分析ステージは単に最良の（そして唯一の）バリアントと各ベンチマークシーケンスのための最適化技法を与えるリストを生成するだけではない：パラメータ範囲のリストは各ベンチマークシーケンスについて、そしてこれらの範囲のそれぞれについて決定され、最良のバリアントと最適化技法が特定される：「最適化ルール」と呼ばれるのはこの種の情報である。

テストされる一組のベンチマークシーケンスは、ベンチマークシーケンスの総数の非常に小さいサブセットである。次に最適化目的に使用されるこのセットは「参照ベンチマークシーケンスのセット」と呼ばれる。

実際は、「合理的な」最適化対象を設定することが非常に重要である：いかなる代償を払っても最適を探索することにより、非常に大きな数のバリアントを得ることが可能になり、一方最適制限を緩和して、最適値の約５％から１０％内にすると、単一のバリアントを非常に広範囲のパラメータにわたって用いることが可能になる。これを行うために、フィルタリングを例えば最適パフォーマンスの９０％の閾値で実装する。

実際はレベル０、１、および２においてベンチマークシーケンスをテストし分析すれば主要な最適化技術を見いだし確認するには十分である。参照ベンチマークシーケンスのセットは一般にレベル３を越えるシーケンスを含まない。

迅速に実行されるべき実験の量は非常に大きく、レベル２を越えると特に大きい。

実験全体としては理想的な態様で並行操作するのに役立つ：テストは１００台または１０００台の機械について並行して実行される。この並列性は非常に有用であり、系統的な研究を許容し得る長さの時間において行うことが可能になる。

このステージは完全に自動化することが可能であり、品質および結果の一貫性の確認手順も自動化することが可能である。人間の介入は品質および一貫性を確認する手順により自動的に生成された結果の分析に由来するエラーおよび／または異常を特定するのに必要とされるだけである。

分析ステージの終点において、目的は、対象アーキテクチャについて特異的に最適化された「カーネル」と呼ばれる、非常に多数の単純なコード断片を利用可能にすることであり、最適化プロセスは本質的に分析ステージの終点において発見された最適化技法に基づいている。

厳密にいうと、「カーネル」はループ型コードシーケンスであり、ベンチマークシーケンスと呼ばれる一般的なケースのサブセットを構成する。ベンチマークシーケンスとは異なり、現実的および有用なコード断片に対応する。ベンチマークシーケンスと同様に、それらは複雑さの昇順でレベルに組織化される。

これらのカーネルの生成および／または最適化は下記の４つのステージを適用して行われる。
・１つ以上のベンチマークシーケンスとの相関：最も単純なカーネルについて、直接的対応がカーネルとベンチマークシーケンスの間に存在するが、より複雑なカーネルについては、カーネルは複数の参照ベンチマークシーケンスに分解されることが必要である。この相関および／または分解はソースレベルでカーネルループ本体の特性：表の数、表アクセス間隔などの関数として実行される。
・コード生成および／または命令の順序づけおよび／または命令の最適化：分析ステージの間に（対応するベンチマークシーケンスの関数として）検出された最適化技法はここでカーネル用のコードを直接用いて生成および／または最適化に提供される。任意の所与のカーネルについて、いくつかの可能なバージョンをパラメータの関数として生成することが可能である。
・レジスタ割当：用いられる最適化技術の多くはレジスタの利用可能性に対する圧力を顕著に増加させる。そのような状況下では、全ての利用可能なレジスタを割り当てる方法を組織することが適切である。
・実験および／または確認：生成され最適化されたカーネルを分析ステージのテストベンチを用いてテストする。このステージの終点において、カーネルのパフォーマンスの簡単なモデルが構築される。

コンパイラに用いられている従来の最適化と比べて、ここで用いられている最適化は非常に異なる：第一に、それらはパフォーマンスを評価する詳細なプロセスから直接導かれる（分析ステージの間に行われる）、その後それらはずっと複雑になり、より高いパフォーマンスになる（特にレジスタの割当について）。その理由は、それらはオフラインで、すなわち時間的「制約」なしに実行されるからである。

参照ベンチマークシーケンスおよび生成ルールを使用すると、第一にアーキテクチャの微細な特性（理論的特性ではなく、むしろ測定された操作特性のすべてを考慮に入れることが可能になり、第二に種々のバージョンをパラメータの関数として選択することができる。

このステージの終点において、最適化カーネルデータベース１６が構築され、これは生成されたカーネルだけでなく、それらのパフォーマンスを種々のパラメータの関数として関連づけた情報も含むものである。各カーネルは、また、ベンチマークシーケンスに用いられるのと同じ手順を用いてテストされる。

実際には、最適化カーネルデータベース１６は系統的かつ網羅的方法でレベル１、２、３、４および５のすべてのカーネルを備える。このデータベースを構築するための計算量としてのコストは大きいが、パフォーマンスの分析ステージと同様に、並行して非常に効率的に実行することが可能である。

ユーザーコード最適化は３つのステージで起きる。
・最適化可能なループの検出（モジュール２０）：これはカーネルに分解することが可能なソースコード中のループを認識することからなる。このステージは自動的並行処理化および／またはベクトル化に用いられる技法と非常によく似た技法を利用する。必要に応じ、ソースコードを再構築してループが最適化に最も適した形で表れるようにする。
・最適ループおよびカーネルへの分解の分析（モジュール２２）：これはカーネル最適化に用いられるものと近似した構造一致および分解技法に基づいており、ループは一連のカーネルに分解される。
・コードのアセンブルおよび投入（モジュール２３）：分解の目的に用いられる種々のカーネルはアセンブルされソースコードに再投入される。

分解手順は一般にオリジナルソースループの特性の関数としてパラーメータ化される。

提案された最適化の統合は：
・存在するコンパイル鎖におけるプリプロセッサにおいて、統合される、これは透明、すなわちコンパイラのコードにアクセスする必要なく行われるか、
・さもなければ直接コンパイラにおいて、統合され、これは当然コンパイラのコードに変更がなされることが必要である。

図３を参照して上述したように分析ステージの終点において歩かずの最適化ルールが利用可能である：これらのルールはベンチマークシーケンスおよびパラメータ範囲の関数である。中間カーネル工程を介して通過する代わりに、一つの可能なバリアントは最適化ループを直接ベンチマークシーケンスと相関させて最適化ルールを最適化ループに、最適化カーネルデータベース１６に格納されたカーネルを利用することなく、直接提供することである。

このバリアントはカーネルを利用するよりも簡単であり、最適化ルールをより柔軟に使用することが可能になる。しかしながら、本質的にインラインで行われるので、探索されるバリアントの数は必然的により小さくなり、その結果、得られるパフォーマンスは先験的に低下する。

最適化ステージの終点において、本システムは歩かずの「最適化可能な」ループに対する最適形態を生成したが、分解操作が必要であったので、これらは先験的にカーネルデータベースにおいて直接利用できなかった。これらの最適化形態はそれ自体最適化カーネルデータベース１６内に格納され、その後再使用することが可能である。従って、カーネルデータベース１６は自動的にこのトレーニング形態で充実される。

図１は本発明に従って最適化コードを自動生成するシステムを構成するモジュールの組を示すブロック図である。 図１のシステムに実装することができるパフォーマンスアナライザモジュールの構造をさらに詳細に示すブロック図である。 図１のシステムに実装することができるコード最適化・生成モジュールの構造をさらに詳細に示すブロック図である。 図４は再組織化されたソースコードを生成するモジュールの第１の実施形態を示すブロック図であり、対応する対象プラットフォームに対して最適化されたバイナリコードの取得に関連している。 図５は再組織化されたソースコードを生成するモジュールの第２の実施形態を示すブロック図であり、対応する対象プラットフォームに対して最適化されたバイナリコードの取得に関連している。

符号の説明

１ ベンチマークシーケンス
２ 静的パラメータ
３ テスト発生器
４ バリアントデータベース
５ 自動ツール（エキササイザ）
６ 結果データベース
７ 動的パラメータ
８ アナライザ
９ 最適化ルールデータベース
１０ アナライザモジュール
１２ 最適化器
１３ 戦略選択モジュール
１６ 最適化カーネルデータベース
１７ （ユーザー）ソースコード
１８ コード生成器（モジュール）
１９ 最適化コード
２０ 最適化ループ検出モジュール
２３ 事例分析・アセンブル・コード投入モジュール
５１、５２、５３ 入力
５７ アナライザモジュール
５５、５７、５９、６２、６３、６４、９３ 移送手段
５８ 最適化ルールを受領する手段
６７、７５ 出力
８０ コード最適化・生成モジュール
８１ コンパイラ
８２ リンクエディタ
８３ 最適化バイナリコード
９０ ハードウェア・プラットフォーム
９１ プロセッサ
９２ カーネルを受領する手段
１８１ コンパイラ１８１
１８２ インストールモジュール
ＣＨＡＲ１〜ＣＨＡＲ４ 特性

Claims (26)

1. ユーザーにより提供されたソースコード（１７）に自動的に動作して、少なくとも１つのプロセッサ（９１）を有し所定の適用分野おいて使用する所定のハードウェア・プラットフォーム（９０）上で動作するのに適した最適化コード（１９）を生成するシステムであって、前記システムは前記所定の適用分野について、前記プロセッサの挙動をパフォーマンスで表す、ベンチマークシーケンス（１）と呼ばれる記号コードシーケンスを受領する手段（５１、５２）；前記所定のハードウェア・プラットフォーム（９０）、そのプロセッサ（９１）、および前記ベンチマークシーケンス（１）に基づいて定義された第１の静的パラメータ（２）を受領する手段（５３）；同じく前記所定のハードウェア・プラットフォーム（９０）、そのプロセッサ（９１）および前記ベンチマークシーケンス（１）から定義された動的パラメータ（７）を受領する手段（５５）；前記ベンチマークシーケンス（１）、前記静的パラメータ（２）および前記動的パラメータ（７）を用いて行われる試験およびパフォーマンスの測定から最適化ルールを作成する分析装置（１０）；第一に前記ベンチマークシーケンス（１）、および第二に前記ユーザーソースコード（１７）を検査するための最適化ルール（９）を受領するコードを最適化・生成する装置（８０）であって、最適化可能な複数のループを検出し、前記複数のループをカーネルに分解し、かつコードをアセンブルおよび投入して前記最適化コード（１９）を引き渡す装置（８０）；およびコードを生成最適化する前記装置から来る情報を再投入し、かつ前記カーネルを前記ベンチマークシーケンス（１）に戻して関連づける手段（７４）を備えたことを特徴とするシステム。
2. 前記分析装置（１０）は、第一に前記ベンチマークシーケンス受領手段（５１）に、第二に前記静的パラメータ受領手段（５３）に接続されたテスト発生器（３）であって、移送手段（６１）により移送されてバリアントデータベース（４）に格納される多数のテストバリアントを自動的に生成するテスト発生器（３）；第一に前記バリアントデータベース（４）に格納された前記テストバリアントを受領する移送手段（６２）に、第二に前記動的パラメータを受領する手段（５５）に接続された前記テストバリアントを前記動的パラメータ（７）の変化の範囲内で実行して移送手段（６３）により移送されて結果データベース（６）に格納される結果を生成するエキササイザ（８）；および前記移送手段（６４）に接続されて前記結果データベース（６）に格納された前記結果を受領し、それらを分析し、かつそれらから、移送手段（５７）により最適化ルールデータベース（９）に移送される最適化ルールを推論するアナライザ（８）を備えることを特徴とする、請求項１に記載のシステム。
3. 前記アナライザ（８）は、最適パフォーマンスに対する任意の閾値を有するフィルタ手段を備え、前記バリアントが前記フィルタ基準を満足する限り、前記結果データベースのバリアントを前記パラメータ空間において最適であると判定するようにしたことを特徴とする、請求項２に記載のシステム。
4. 前記アナライザ（８）は、さらに前記静的パラメータ（２）を変更する手段（５４）および前記動的パラメータ（７）を変更する手段（５６）を備えることを特徴とする、請求項３に記載のシステム。
5. 前記コードを最適化および生成する装置（８０）は、最適化コードを生成する装置（１８）と最適化器（１２）とを備え、前記最適化器は第一に前記オリジナルソースコード中に特定されたカーネルを受領する手段（９２）に、第二に前記ベンチマークシーケンス（１）を受領する手段（５２）に、および第三に前記最適化ルール（９）を受領する手段（５８）に接続された戦略選択モジュール（１３）であって、テストされたベンチマークシーケンスに対応するそれぞれのカーネルについてそれぞれあるパラメータの組合せの下で最適である複数のバージョン（１５）を生成する戦略選択モジュールと、前記最適化ルール（９）を受領する手段（５９）に、前記戦略選択モジュール（１３）から来る情報を受領する手段（６６）に、および前記複数のバージョンを受領する手段（６８）に接続された組合せ・アセンブルモジュール（１４）とを備え、移送手段（９３）を介して、前記対応する最適化バージョン、それらの使用帯域、および必要に応じて前記実行されるべきテストを含む情報を引き渡してどのバージョンが最も適しているかを動的に決定するようにしたことを特徴とする、請求項１〜４のいずれか一項に記載のシステム。
6. 前記システムは最適化カーネルデータベース（１６）を備え、前記組合せ・アセンブルモジュール（１４）は移送手段（７９）により前記最適化カーネルデータベース（１６）に接続されて前記最適化カーネルデータベースに情報を格納し、前記情報は前記最適化バージョン、それらの使用帯域、および必要に応じて実行されるべきテストを含む情報をどのバージョンがもっとも適しているかを動的に決定するようにしたことを特徴とする、請求項５に記載のシステム。
7. 前記コード最適化・生成装置（８０）は最適化器（１２）と最適化コード生成装置（１８）とを備え、前記最適化コード生成装置はユーザーソースコード（１７）を受領する手段（７１）に接続された最適化可能ループ検出手段（２０）、それらをカーネルに分解するモジュール（２２）、移送手段（９２）を介して前記最適化器（１２）に接続されて前記検出されたカーネルのアイデンティティー（識別情報）を伝送するようにした事例分析、アセンブルおよびコード投入モジュール、および前記対応する最適化カーネルを記載する情報を受領する移送手段（９３）を備え、前記事例分析、アセンブルおよびコード投入モジュール（２３）も最適化コード供給手段（７３）に接続されていることを特徴とする、請求項１〜６のいずれか一項に記載のシステム。
8. 前記事例分析、アセンブルおよびコード投入モジュール（２３）も前記最適化カーネルデータベース（１６）に接続され、最適化カーネルを記載する情報を、前記検索された最適化カーネルがそこに格納されているならば、前記最適化器（１２）を呼び出すことなく、受領するようにしたことを特徴とする、請求項６または７に記載のシステム。
9. 前記事例分析、アセンブルおよびコード投入モジュール（２３）は、さらに、前記ベンチマークシーケンスに前記事例分析、アセンブルおよびコード投入モジュールにおいて発見されたカーネルを、前記最適化カーネルデータベースまたはベンチマークシーケンス（１）のいずれにおいても対応するアイデンティティー（識別情報）を持たずに追加する手段（７４）を備えることを特徴とする、請求項８に記載のシステム。
10. 前記システムはコンパイラ（８１）とリンクエディタ（８２）とを備え、再組織化されたソースコード（１９）を前記コード最適化・生成装置（８０）から受領し、前記ハードウェア・プラットフォーム（９０）に適合された最適化バイナリコード（８３）を生成することを特徴とする、請求項６、８および９のいずれか一項に記載のシステム。
11. 前記システムは、前記最適化カーネル用の前記ソースコードを前記最適化カーネルデータベース（１６）から前記コンパイラ（８１）に移送する手段（８５）を備えたことを特徴とする、請求項１０に記載のシステム。
12. 前記システムはコンパイラ（１８１）と、動的ライブラリを前記ハードウェア・プラットフォーム（９０）上にインストールするインストールモジュール（１８２）とを備え、前記ライブラリは前記最適化カーネルの能力の全てを含むことを特徴とする、請求項１０に記載のシステム。
13. 前記所定の適用分野は科学計算であることを特徴とする、請求項１〜１２のいずれか一項に記載のシステム。
14. 前記所定の適用分野は信号処理であることを特徴とする、請求項１〜１２のいずれか一項に記載のシステム。
15. 前記所定の適用分野はグラフィックス処理であることを特徴とする、請求項１〜１２のいずれか一項に記載のシステム。
16. 前記ベンチマークシーケンス（１）は、ソース型言語で特定され、かつループ本体用のコードの複雑さの昇順により階層レベルで組織化された一組の単純かつ包括的ループ型コード断片を含むことを特徴とする、請求項１〜１５のいずれか一項に記載のシステム。
17. 前記ベンチマークシーケンスは、唯一の個別動作がテストされ、高さ０のツリーによって表される単一の演算式により構成されるループ本体に対応するレベル０のベンチマークシーケンスを含むことを特徴とする、請求項１６に記載のシステム。
18. 前記ベンチマークシーケンスは、レベル２のベンチマークシーケンスを含んでいてもよく、前記ベンチマークシーケンスに対しては、２つのレベル０の操作の組合せ；および高さ１のツリーによって表される単一の演算式により、またはそれぞれ高さ０のツリーによって表される２つの演算式により構成されるループ本体に対応するレベル１のベンチマークシーケンス操作が考えられ、かつテストされることを特徴とする、請求項１７に記載のシステム。
19. 前記ベンチマークシーケンス（１）は、レベル１のベンチマークシーケンスを含み、前記ベンチマークシーケンスに対して２つのレベル１の操作または３つのレベル０の操作が考えられ、かつテストされることを特徴とする、請求項１８に記載のシステム。
20. 前記静的パラメータ（２）は、特に各ベンチマークシーケンスのループ反復数、表アクセス間隔、およびオペランド型、使用命令の型、先行載荷（プリロード）戦略、および命令および反復の順序づけ戦略を含むことを特徴とする、請求項１６〜１９のいずれか一項に記載のシステム。
21. 前記動的パラメータ（７）は、特にメモリ階層の種々のレベルにおける表オペランドの位置、表開始アドレスの相対的位置、および分岐履歴を含むことを特徴とする、請求項１６〜２０のいずれか一項に記載のシステム。
22. 前記最適化カーネルデータベース（１６）は、現実の有用な、複雑さの昇順に階層レベルに組織化されたコード断片に対応するループ型ソースコードシーケンスを含むことを特徴とする、請求項６、８および９のいずれか一項に記載のシステム。
23. 前記所定のハードウェア・プラットフォーム（９０）は、イタニウム（Ｉｔａｎｉｕｍ^TM）型の少なくとも１つのプロセッサを備えたことを特徴とする、請求項１〜１２のいずれか一項に記載のシステム。
24. 前記所定のハードウェア・プラットフォーム（９０）は、ＩＢＭ社から供給されたパワー（Ｐｏｗｅｒ）またはパワーＰＣ（Ｐｏｗｅｒ ＰＣ^TM）型の少なくとも１つのプロセッサを備えたことを特徴とする、請求項１〜１２のいずれか一項に記載のシステム。
25. 前記所定のハードウェア・プラットフォーム（９０）は、イタニウム（Ｉｔａｎｉｕｍ ^TM ）型の少なくとも１つのプロセッサを備えており、
    前記最適化ルール（９）は下記のルールのうち、少なくとも幾つか：
    ａ）書込パフォーマンスが読取パフォーマンスに比べて劣っている場合、書込の数を最小化する；
    ｂ）浮動小数点におけるローディングペアの使用の重要性；
    ｃ）ループがループ本体の複雑さの関数として展開される程度を調整する；
    ｄ）演算操作における操作待ち時間を用いる；
    ｅ）短いベクトルに対してマスキング技術を使用する；
    ｆ）メモリアクセス（読取、書込、プリローディング）用の局所さフィックスを用いる；
    ｇ）プリローディング距離を定義する；
    ｈ）程度４のベクトル化を実行してＬ２バンクの衝突の若干を回避する；
    ｉ）複数のバリアントを考慮に入れて他のＬ２バンクの衝突と、読取／書込キーにおける衝突とを回避する；
    ｊ）種々の最適化に関連するパフォーマンス改善を考慮に入れる；
    ｋ）誤った予測（短いベクトル）を最小化する分岐鎖を用いる；
    ｌ）メモリアクセスを統合する（ピクセルを一緒のグループにする）；および
    ｍ）ピクセルにベクトル化処理をする
    を含むことを特徴とする、請求項１３〜１５のいずれか一項に記載のシステム。
26. 前記所定のハードウェア・プラットフォーム（９０）は、ＩＢＭ社から供給されたパワー（Ｐｏｗｅｒ）またはパワーＰＣ（Ｐｏｗｅｒ ＰＣ ^TM ）型の少なくとも１つのプロセッサを備えており、
    前記最適化ルール（９）は下記のルールのうち、少なくとも幾つか：
    ａ）読取値を再順序づけしてキャッシュ欠陥をまとめる；
    ｂ）書込値に対してのみプリローディングを用いる；
    ｃ）ループがループ本体の複雑さの関数として展開される程度を調整する；
    ｄ）演算操作における操作待ち時間を用いる；
    ｅ）メモリアクセス（読取、書込、プリローディング）用の局所サフィックスを用いる；
    ｆ）プリローディング距離を定義する；
    ｇ）複数バリアントを考慮に入れて読取／書込キーにおける衝突を避ける；および
    ｈ）種々の最適化に関連するパフォーマンス改善を考慮に入れる
    を含むことを特徴とする、請求項１３〜１５のいずれか一項に記載のシステム。

Images