この記事は、インテルの The Parallel Universe Magazine 29 号に収録されている、OpenMP* 言語委員会の委員長であり、Livermore Computing の CTO である Bronis R. de Supinski 氏の OpenMP* 20 周年に関する寄稿の章を抜粋翻訳したものです。
私は、20 年という歳月を経て OpenMP* がようやく成人したと感じています。OpenMP* 20 周年のさまざまなイベントは、OpenMP* 仕様の原点と発展を改めて見直す機会を与えてくれました。OpenMP* 言語委員会の委員長として (OpenMP* 3.0 のリリース直後から約 9 年間務めています)、この回顧録ならびに OpenMP* 組織の現況と将来の計画を発表する機会が得られたことを嬉しく思っています。私は、OpenMP* がそのルーツに忠実なまま、今後 20 年間さらなる発展を遂げることに、皆さんも同意されることを期待しています。
OpenMP* は、ループベースの共有メモリー並列処理に対応するため、多くのコンパイラー・メーカーがまだ標準化されていないディレクティブをサポートしていた時代に生まれました。これらのディレクティブは効果的でしたが、重要な要件である移植性に欠けていました。これらの実装固有のディレクティブは、構文 (スペリング) が異なっているだけでなく、しばしばセマンティクスにも微妙な違いがありました。この欠点に気付いていたローレンス・リバモア国立研究所の Mary Zosel 氏は、各メーカーと密接に協議して、共通の構文とセマンティクスについて合意を取り付け、OpenMP* 1.0 の提供にこぎつけました。さらに、彼らは OpenMP* の権利を所有し、OpenMP* 仕様を管理する組織を創立しました。
多くの人は、OpenMP* のルーツを、単純に最初の仕様で標準化されたループベースの共有メモリー・ディレクティブとしてとらえているでしょう。私は、OpenMP* のルーツを、コンパイラー・メーカーとシステムができるだけ移植性の高いパフォーマンスを提供することを求めるユーザー組織による、移植性のあるディレクティブ・ベースの並列化と最適化 (プロセス内に制限された) をサポートする取り組みであると考えています。OpenMP* は、コンパイラーが (スタティック) 解析により引き出すことが困難または不可能であると判断した、アプリケーションに対するパフォーマンスを明示的に表現するプログラマー向けのメカニズムである、と私は思っています。組織的には、OpenMP* は、すべての主要コンパイラー・メーカー並びに活発で成長を続けるユーザー組織を含む多くの会員を擁し、活気に満ちた活動を行っています。
技術的には、OpenMP* 仕様は、利用可能なループベースの並列処理ディレクティブを統一するという本来の目標を達成しました。現在も、その目的のために、単純で、適切に定義された構文の改良を続けています。さらに、OpenMP* は、ループを結合する機能や、並列化されたコードを実行するスレッドの配置を制御する機能など、ディレクティブの改良も続けています。これらの構文は、共有メモリー・アーキテクチャーおよびコンパイラー全体にわたって一貫した強力なパフォーマンスを達成し、OpenMP* 誕生の動機となった移植性を提供します。
OpenMP* の発展とともに、いくつかの新たな並列処理も採用されました。私は、コミュニティーに参加する人々がタスクベースの並列処理のメカニズムの標準化が必要であるという話をしているのを聞くとうんざりします。OpenMP* は 9 年も前から標準化されたメカニズムを提供しています。2008 年に、完全なタスクベースのモデルを採用した OpenMP* 3.0 仕様がリリースされました。OpenMP* のタスク実装はまだ改善できると私は考えていますが、現在はどちらとも決めかねる問題に直面しています。一貫して強力なパフォーマンスを提供するモデルが実装されれば OpenMP* タスクを使用する、とユーザーが述べているのをよく聞きます。また、モデルの採用が進めばタスクの実装を最適化する、とメーカーが述べているのもよく聞きます。別の視点から見た OpenMP* タスクモデルの問題は、1 つのアプリケーションですべて使用できるように、一連の並列化手法に一貫した構文とセマンティクスを提供するという、OpenMP* の長所によるものです。このような一般化のサポートには、オーバーヘッドがつきものです。しかし、モデルを改良することで、オーバーヘッドを多少緩和できます。例えば、OpenMP* 3.1 では、複雑なコンパイラー解析や複雑なプログラム構造に依存しない、最小タスク粒度を指定する final 節 (および関連する概念) が追加されています。我々は、将来の OpenMP* 仕様に取り組むとともに、OpenMP* タスクのオーバーヘッドを軽減する方法を見い出そうとしています。
