【文献】
上村 純平 外2名,GPU援用カラムストアデータベースの設計と評価,情報処理学会研究報告 2011(平成23)年度 2 [CD−ROM],日本,一般社団法人情報処理学会,2011年 8月29日,1−7頁
【文献】
立川 純,超並列コンピューティング環境 GPGPUプログラミング,月刊アスキードットテクノロジーズ 第15巻 第8号,日本,株式会社アスキー・メディアワークス,2010年 6月29日,36−47頁
【文献】
田村 陽介 外2名,驚異の1TFLOPSオーバーパワーを徹底活用 GPGPUによる並列処理,月刊アスキードットテクノロジーズ 第14巻 第12号,日本,株式会社アスキー・メディアワークス,2009年10月27日,78−85頁
(58)【調査した分野】(Int.Cl.,DB名)
外部ネットワークを介して相互接続される、ホストコンピュータと、疎結合型アクセラレータとして機能する少なくとも1つのアクセラレータ装置との間で実行される分散計算方法であって、前記分散計算方法は、
データサイズの範囲についてデータ転送速度および計算速度を性能分析し、前記外部ネットワークを経由するデータ転送に最適なチャンクサイズを、前記データ転送速度を、チャンクからフレーム形成する速度およびチャンクを計算する速度を含む計算速度で除算した値として定義される、重なり比が1に最も近くなるようなデータサイズに、決定するステップと、
前記ホストコンピュータのメモリ内に格納されたあるサイズのデータを分割または集約して、前記最適なチャンクサイズを有するチャンクに該データをカプセル化するステップと、
カプセル化されたデータを前記アクセラレータ装置に振り分けるステップと、
前記アクセラレータ装置に対し、受信した前記カプセル化されたデータに関してパイプライン計算を命令するステップと
を含み、
前記重なり比は、実際にかかった転送時間から計算され、前記重なり比が1に最も近くなるようなデータサイズが複数存在する場合は、前記最適なチャンクサイズは、最小データサイズと最大データサイズとの間で最大のデータ転送速度を有するデータサイズに決定される、
分散計算方法。
前記最適なチャンクサイズは、計算速度に関して前記性能分析するステップ中に送信された最小データサイズと最大データサイズとの間で、最大のデータ転送速度を有するデータサイズに決定される、請求項1に記載の分散計算方法。
前記データのカプセル化について、前記データのサイズが前記最適なチャンクサイズよりも大きい場合に前記データに前記分割が適用され、前記データのサイズが前記最適なチャンクサイズよりも小さい場合に前記データは前記集約に施される、請求項1に記載の分散計算方法。
外部ネットワークを介して相互接続される、ホストコンピュータと、疎結合型アクセラレータとして機能する少なくとも1つのアクセラレータ装置との間で分散計算するためのプログラムであって、前記プログラムは、前記ホストコンピュータに対し、
データサイズの範囲についてデータ転送速度および計算速度を性能分析し、前記外部ネットワークを経由するデータ転送に最適なチャンクサイズを、前記データ転送速度を、チャンクからフレーム形成する速度およびチャンクを計算する速度を含む計算速度で除算した値として定義される、重なり比が1に最も近くなるようなデータサイズに、決定するステップと、
前記ホストコンピュータのメモリ内に格納されたあるサイズのデータを分割または集約して、前記最適なチャンクサイズを有するチャンクに該データをカプセル化するステップと、
カプセル化されたデータを前記アクセラレータ装置に振り分けるステップと、
前記アクセラレータ装置に対し、受信した前記カプセル化されたデータに関してパイプライン計算を命令するステップと
を実行させ、
前記重なり比は、実際にかかった転送時間から計算され、前記重なり比が1に最も近くなるようなデータサイズが複数存在する場合は、前記最適なチャンクサイズは、最小データサイズと最大データサイズとの間で最大のデータ転送速度を有するデータサイズに決定される、
プログラム。
前記最適なチャンクサイズは、計算速度に関して前記性能分析するステップ中に送信された最小データサイズと最大データサイズとの間で、最大のデータ転送速度を有するデータサイズに決定される、請求項7に記載のプログラム。
前記データのカプセル化について、前記データのサイズが前記最適なチャンクサイズよりも大きい場合に前記データに前記分割が適用され、前記データのサイズが前記最適なチャンクサイズよりも小さい場合に前記データに前記集約が適用される、請求項7に記載のプログラム。
前記アクセラレータ装置は、アプリケーション・プログラムを実装するコンピュータから選択され、前記アクセラレータ装置は、TCP/IPネットワークを用いて前記ホストコンピュータとネットワーク接続される、請求項7に記載のプログラム。
外部ネットワークを介して相互接続される、ホストコンピュータと、疎結合型アクセラレータとして機能する少なくとも1つのアクセラレータ装置との間の分散計算を実行する前記ホストコンピュータであって、前記ホストコンピュータは、
データサイズの範囲についてデータ転送速度および計算速度を性能分析するプロファイラ部と、
性能分析された前記データ転送速度および前記計算速度から、前記外部ネットワークを経由するデータ転送に最適なチャンクサイズを、前記データ転送速度を、チャンクからフレーム形成する速度およびチャンクを計算する速度を含む計算速度で除算した値として定義される、重なり比が1に最も近くなるようなデータサイズに、決定するサイズ最適化部と、
前記ホストコンピュータのメモリ内に格納されたあるサイズのデータを分割または集約することによって、前記最適なチャンクサイズを有するチャンクに該データをカプセル化するカプセル化部と、
カプセル化されたデータを前記アクセラレータ装置に振り分け、かつ、該アクセラレータ装置に対し、受信した前記カプセル化されたデータに関してパイプライン計算を命令するディスパッチャ部と
含み、
前記重なり比は、実際にかかった転送時間から計算され、前記重なり比が1に最も近くなるようなデータサイズが複数存在する場合は、前記最適なチャンクサイズは、最小データサイズと最大データサイズとの間で最大のデータ転送速度を有するデータサイズに決定される、
ホストコンピュータ。
前記最適なチャンクサイズは、計算速度に関して前記プロファイラ部により送信された最小データサイズと最大データサイズとの間で、最大のデータ転送速度を有するデータサイズに決定される、請求項12に記載のホストコンピュータ。
前記ディスパッチャ部は、前記アクセラレータ装置内のバッファ・オブジェクトへのチャンク数分の前記カプセル化されたデータの複数書き込みを命令し、前記カプセル化されたデータの受信に際して、前記カプセル化されたデータへの前記アクセラレータ装置の演算の実行を命令する、請求項12に記載のホストコンピュータ。
TCP/IPネットワークを介して相互接続される、ホストコンピュータと、疎結合型アクセラレータとして機能する少なくとも1つのアクセラレータ装置とを含む分散計算システムであって、前記アクセラレータ装置は、アプリケーション・プログラムを実装し、前記ホストコンピュータは、
データサイズの範囲についてデータ転送速度および計算速度を性能分析するプロファイラ部と、
性能分析された前記データ転送速度および前記計算速度から、前記外部ネットワークを経由するデータ転送に最適なチャンクサイズを、前記データ転送速度を、チャンクからフレーム形成する速度およびチャンクを計算する速度を含む計算速度で除算した値として定義される、重なり比が1に最も近くなるようなデータサイズに、決定するサイズ最適化部と、
前記ホストコンピュータのメモリ内に格納されたあるサイズのデータを分割または集約することによって、前記最適なチャンクサイズを有するチャンクに該データをカプセル化するカプセル化部と、
カプセル化されたデータを前記アクセラレータ装置に振り分け、かつ、該アクセラレータ装置に対し、受信した前記カプセル化されたデータに関してパイプライン計算を命令するディスパッチャ部と
を含み、
前記最適なチャンクサイズは、計算および通信の前記重なり比が1に最も近いデータサイズに決定され、前記重なり比が1に最も近くなるようなデータサイズが複数存在する場合は、最小データサイズと最大データサイズとの間で最大のデータ転送速度を有するものに決定され、
前記ディスパッチャ部は、前記アクセラレータ装置内のバッファ・オブジェクトへのチャンク数分の前記カプセル化されたデータの複数書き込みを命令し、前記カプセル化されたデータの受信に際して、前記カプセル化されたデータへの前記アクセラレータ装置の演算の実行を命令する、分散計算システム。
【背景技術】
【0002】
近年、計算効率および/または計算速度を高めるためにGPU(Graphic Processor Units)を用いたマルチプロセッサ計算が広く利用されている。GPUは、典型的には、計算性能を高めるためメインCPUのアクセラレータとして用いられる。上述のようなマルチプロセッサ計算アーキテクチャでは、PCIまたはPCI−Expressなどの内部バスを介して接続されたGPUネットワークがよく用いられる。ここでは、上述のような内部バスを介して接続されたGPUを、密結合型アクセラレータ装置(Tightly-Coupled Accelerator Devices)と参照する。
【0003】
GPUは、適切なプログラム言語によって、ホストCPUの制御の下、並列動作して計算性能を高めている。上述したようなプログラム言語の一例としては、OpenCLを挙げることができる。OpenCLは、ホストCPUおよびGPU間のデータ転送を管理するために適用することができ、本発明では、このデータ転送における性能コストを最小化するため利用することができる。
【0004】
他のスキームのマルチプロセッサ計算アーキテクチャは、例えば、分散コンピューティングまたはグリッド・コンピューティングとして知られている。これらのマルチプロセッサ計算アーキテクチャは、ホストコンピュータまたはマスタコンピュータの制御下で計算を分担する複数のサーバまたはコンピュータを含むことができる。このタイプのマルチプロセッサ計算アーキテクチャでは、コンピュータ間は、イーサネット(登録商標)などの外部バスネットワークと種々の物理接続プロトコルを用いたネットワーク・インタフェース・カードとを用いて接続される。コンピュータは、ネットワーク内で実行される計算全体をサポートすることができ、分散計算を担当するコンピュータは、アクセラレータと見なすことができる。しかしながら、上記分散計算アーキテクチャにおけるコンピュータは、外部ネットワークを介してTCP/IPで接続されており、よって、分散計算システム内のコンピュータは、疎結合型アクセラレータ(loosely-coupled accelerators)と見なすことができる。
【0005】
疎結合型マルチプロセッサ・システムでは、コンピュータまたはノードは、外部ネットワークを介して接続される。このため、ホストコンピュータおよびアクセラレータ間のデータ転送は、データサイズ、ランタイム実装やネットワーク状態などの転送条件の影響を受ける可能性がある。
【0006】
TCPネットワークを経由した計算の性能強化は、これまでも開発されており、米国特許出願公開第2008/0295098号明細書(特許文献1)は、大きなTCPセグメントを小さなTCPセグメントで動的にセグメント化し、割り込み頻度を低減するコンピュータ・システムを開示する。特開2011−170732号公報(特許文献2)は、機能ブロックをストランドに分け、計算時間に依存して機能ブロックを修正する並列コンピューテーション方法を開示する。
【0007】
密結合型アクセラレーション・アーキテクチャにおいては、多数の少量の転送を1つの大きな転送にバッチ化して、データ転送性能を向上する技術が提案されている(NVIDIA,OpenCL Best Practice Guide,Section 3.1 ”Data Transfer between Host and Device”を参照のこと)。さらに、Kim等は、非特許文献1において、データ並列プログラム中で通信レイテンシを隠蔽するために通信および計算をオーバラップさせるモデルを開示する。
【発明を実施するための形態】
【0019】
以下、本発明について特定の実施形態に基づいて説明するが、説明する実施形態は、単に最良の実施形態を説明するものであり、本発明を限定するものではない。以下、
図1を参照して、疎結合型システムにおける分散計算のデータ転送コストについて、OSI基本参照モデルを用いて説明する。システム内のノード各々は、通常、物理層103、ネットワーク層102およびトランスポート層101を含む。物理層103は、イーサネット(登録商標)フレームの受信および送信を担当する。ネットワーク層102は、適切なデータサイズのペイロードを持つIPパケットの形成を担当する。トランスポート層101は、アプリケーション層100内のアプリケーションによって処理されたデータからTCPパケットを形成する。アプリケーション層100は、アプリケーションにおけるデータの計算によって、ランタイム・オーバヘッドとしてそのコストを支払う。
【0020】
トランスポート層101、ネットワーク層102および物理層103は、それぞれ対応する処理コストに寄与し、アプリケーション全体に対するコストは、ノードから他のノードへTCP/IPパケットとして転送されるデータサイズに影響される可能性がある。上記データサイズの影響は、密結合型システムとは対照的に、計算およびスケーラビリティに余分なコストを生じさせる可能性がある。
【0021】
図2は、本発明の例示的な分散計算システム200のブロック図である。本システム200は、例えばメインフレーム201、サーバ202、ブレード型サーバがラック内に配置されるラックマウント・サーバ203といった種々の計算プラットフォームを含む。メインフレーム201は、IBM System/390といったSystem zシリーズから選択することができるが、他のアーキテクチャのメインフレームを用いてもよい。サーバ202およびラックマウント・サーバ203内のブレード型サーバは、IBM POWER、Power Series(登録商標)で実装されるPowerPC(登録商標)などのCPU/CPUsを含み構成される。
【0022】
これに対して、プラットフォーム204は、x86アーキテクチャとも参照される、Intel XEON(登録商標)といったCPU/CPUsを含むことができる。
図2に示すプラットフォームは、それぞれ、異なるオペレーティング・システムおよびアプリケーション・プログラムがインストールされ、オペレータまたはユーザから要求されたサービスを提供する。プラットフォームは、ハブ/スイッチ210およびルータ230を経由して、イーサネット(登録商標)または光通信を用いるFTTHといった適切なネットワーク220によって接続される。プラットフォームは、さらに、RAM、ROM、ハードディスク・ドライブ、ギガビット・レートのネットワーク・インタフェース・カードなどを含み、オペレータに業務アプリケーション・サービスを提供する。
【0023】
プラットフォームは、TCP/IPプロトコルを通じて、ネットワークを経由してデータ、コマンドおよびメッセージを通信し、本発明においては、プラットフォームは、疎結合型アーキテクチャによる分散計算環境を提供する。分散計算は、これまで知られた如何なるプロトコルまたは技術を用いることによって可能であるが、既存のアプリケーション・リソースを用いてプラットフォーム間の差異を乗り越える観点からは、OpenCLアーキテクチャが有用である。
【0024】
図3は、疎結合型システムを構築するためのプラットフォームの機能ブロック
図300である。プラットフォーム310はホストの役割を担い、プラットフォーム320はアクセラレータ装置の役割を担う。ここで、用語「アクセラレータ装置」または、より簡単に「アクセラレータ」は、分離されたコンピュータまたは情報処理装置を参照し、このコンピュータまたは情報処理装置は、ホストと通信して、該ホストの全体計算を高速化する。ホストは、その機能手段として、ホスト・アプリケーション311と、ホスト310に実装されたアプリケーション・カーネル・プログラム312と、ランタイム環境313と、ソケット・インタフェース314とを含み構成される。
【0025】
ホスト・アプリケーション311は、プロファイラ部311aと、サイズ最適化部311bと、カプセル化部311cと、ディスパッチャ部311dとを含み構成される。プロファイラ部は、最小サイズ(MIN_SIZE)から最大サイズ(MAX_SIZE)までのデータサイズの範囲について、データ転送速度および計算速度を性能分析する。ここで、最小サイズ(MIN_SIZE)および最大サイズ(MAX_SIZE)は、アプリケーション・プログラムにおいて、ホストおよびアクセラレータ装置間で転送される可能なデータサイズである。サイズ最適化部311bは、性能分析されたデータ転送速度および計算速度に基づいて、ネットワークを経由するデータ転送に最適なチャンクサイズを見つけ出し、決定する。
【0026】
カプセル化部311cは、ホストコンピュータのメモリ内に格納されたデータを、最適なチャンクサイズを有するチャンクに分割または集約することによって、カプセル化する。ディスパッチャ部311dは、カプセル化されたデータをアクセラレータ装置に振り分けると共に、アクセラレータ装置に対し、受信したカプセル化されたデータに関してパイプライン計算を命令する。なお、プロファイラ部311a、サイズ最適化部311b、カプセル化部311cおよびディスパッチャ部311dは、ホスト・アプリケーション311の一部である必要はなく、これらのいくつかはランタイム環境313の一部であってもよい。
【0027】
ホスト・アプリケーション311は、カーネル・プログラム312の制御により、ユーザに対し種々のサービスを提供し、説明する実施形態では、OpenCL APIが、ホスト・アプリケーションの一つのモジュールとして実装されてもよい。カーネル・プログラム312は、z/OS、UNIX(登録商標)、Linux(登録商標)、またはWindows(登録商標)200X Server用に実装され、ホストの種々の動作を制御する。
【0028】
特定の実施形態では、ホストは、疎結合型システムを実装するため、カーネル312の1つのコンポーネントとしてOpenCLカーネル・プログラムを含む。ランタイム環境313は、OpenCLランタイム、ホストのランタイム状態をサポートするダイナミック・リンク・ライブラリなどのランタイム・ライブラリを含む。ソケット・インタフェース314は、ソケット通信を用いて、TCP/IPパケットをアクセラレータ装置320に送信し、説明する実施形態では、Socket Send/Recieve、RDMA R/Wメソッドまたはクラスが、OpenCLアーキテクチャをサポートするための1つのモジュールとして実装される。
【0029】
アクセラレータ装置320は、アプリケーション・カーネル321と、バッファ・オブジェクト322と、ランタイム環境323と、ホスト310へのプロキシ機能部324と、ソケット・インタフェース325とを含み構成される。アプリケーション・カーネル321は、要求されたサービスを提供し、バッファ・オブジェクト322は、アクセラレータ装置320で使用される種々の情報を格納する。説明する実施形態では、バッファ・オブジェクト322は、疎結合型システムのアクセラレータ装置として、入力データおよびコマンドを受信し、またアプリケーション・カーネル・プログラム321からの計算結果を送信する。
【0030】
ランタイム環境323は、その機能コンポーネントとして、プラットフォームのアーキテクチャに適合するOpenCLコンパイラおよびランタイム・ライブラリを含み、OpenCL関数を実装するプロキシ機能部324とともに、ホスト310から命令された演算を実行する。ソケット・インタフェース325は、ソケット通信を介してホストと通信し、ネットワーク330を経由したホスト310に対するSocket Send/Receive、RDMA R/Wメソッドまたはクラスを含み構成される。
【0031】
したがって、疎結合型システムは、2種類のデータ処理コストを含み、1つは計算およびフレーム形成コストであり、他の1つはネットワークを経由するデータ転送コストである。この2種類のコスト、つまり、計算コストおよびデータ転送コストは、分散計算環境における円滑かつ効率的な計算のため良くバランスされ、通信レイテンシの待機時間を最小化することが好ましい。換言すれば、データ転送速度および計算速度は、アクセラレータ装置内のハードウェア・リソースを浪費しないように最適化される必要がある。
【0032】
図4は、本分散計算システムの処理を示すフローチャートである。
図4に示す処理は、ステップS400から開始され、ホストは、ネットワーク状態およびアクセラレータ装置のハードウェア状態を検査し、システムにおける最適なチャンクサイズを決定する。ステップS400の詳細は後述するが、ステップS400では、ホストは、ネットワークを経由して、アクセラレータ装置によるテスト計算を行い、その応答時間を測定する。ステップS401では、ホストは、転送データのためのバッファおよびサブバッファのサイズを割り当てる。ここで、バッファのサイズは、対象とされる計算のデータサイズにより決定することができ、サブバッファのサイズは、最適なチャンクサイズに設定することができる。あるいはその反対とすることができる。説明する好適な実施形態において、いずれとなるかは、データ分割またはデータ集約のどちらが適用されるかに依存する。
【0033】
ステップS402では、対象とされる計算用のデータが分割または集約されて、これによって、アクセラレータ装置に転送されるデータサイズが最適なサイズを有するサブバッファ内に収容されるようになる。ステップS403では、ホストは、最適なサイズを有するデータを、アクセラレータ装置内での計算のためのコマンドまたは命令と共に送信する。説明する実施形態では、アクセラレータ装置上での計算の命令は、OpenCL言語によりコード化されるものとするが、しかしながら、その他の分散計算プロトコルを使用してもよい。
【0034】
ステップS404では、ホストは、データ分割が適用され、かつアクセラレータ装置に割り当てられたアプリケーション・カーネル・タスクが結合可能型であるか、つまり、タスクが分割データについてパイプライン実行を適用できるかを判定する。肯定的である場合(yes)は、ホストは、アクセラレータ装置にパイプライン化された計算を開始させるための命令を転送し、アクセラレータ装置で、データ通信と重複させて計算を実行させる。一方、タスクがパイプライン計算に適合していない場合(no)は、ホストは、パイプライン処理を行わない通常の疎結合型計算命令コードを転送し、
図4に示す処理は、アクセラレータ装置によるステップS405へ進められる。
【0035】
ステップS405〜ステップS408の処理は、計算を担当するアクセラレータ装置において実行される処理である。ステップS405では、アクセラレータ装置は、データおよび命令を受信し、アクセラレータ装置は、ここでは計算が結合可能型ではなく、計算の投機的な開始が不正であるため、すべてのデータチャンクが受信されるまで待機する。ステップS405に処理が進められると、アクセラレータ装置は、計算に必要なデータ全体を受信した後に計算を開始し、ステップS408で、計算の結果をホストに返す。
【0036】
ステップS404の判定で、肯定的な結果が戻された場合(yes)は、ステップS406へ処理が進められ、アクセラレータ装置は、最適化された計算および通信の重なりをもって、順次受信されたデータチャンクおよび命令に対して、パイプライン化された計算の実行を開始する。アクセラレータ装置は、連続して送信されたデータチャンクに対してパイプライン実行による計算を最後まで続け、アクセラレータ装置は、結合演算を呼び出して、パイプライン化された計算で得られた各部分結果を結合する。アクセラレータ装置は、計算された結果をホストに返し、ホストから受信したコマンドを完了させる。
【0037】
図5は、
図4におけるステップS400「最適なチャンクサイズを決定する」の詳細な処理を示す。本処理は、ステップS500から開始し、ホストは、所与のランタイムおよびネットワーク環境において、ホストからアクセラレータへの経路とアクセラレータからホストへの経路との両方について別個に、データ転送コストおよび計算パイプライン効果を性能分析する。そして、ステップS501では、ホストは、適切なサンプル計算セットを用いて、経過時間(elapsedTime1およびelapsedTime2で参照する)に相当するデータ転送速度および計算速度を決定する。ここで、「elapsedTime1」および「elapsedTime2」は、性能分析処理で得られる変数である。
【0038】
ステップS502では、ホストは、パラメータ(elapsedTime1およびelapsedTime2)を用いて重なり比を計算する。本実施形態において、「重なり比」とは、計算速度に対する転送速度の比として定義され、好ましくは、データ転送速度と計算速度とが等しい場合に1となる。
【0039】
続いてステップS503では、ホストは、ネットワークおよびデバイスの与えられた性能の下で、より高いデータ転送速度を求めつつ、重なり比が1に最も近くなるような、最適化されるべきチャンクのデータサイズを決定する。そして、ホストは、
図4中ステップS400で決定された最適なチャンクサイズを用いて、アクセラレータ装置へ転送すべき計算の命令の準備を開始する。
【0040】
図6は、
図5(ステップS500)においてホストからアクセラレータ装置への経路(以下、経路h2aと参照する)についてのデータ転送コストおよび計算コストを性能分析する詳細な処理を示す。
図6に示す処理は、ステップS600から開始され、ホストは、ステップS601では、テスト計算用データを送信するために用いる書き込み用のグローバル・バッファを割り当て、その後、ホストは、タイマ・オブジェクトを開始する。ホストは、最小サイズ(MIN_SIZE)から最大サイズ(MAX_SIZE)までの範囲でサンプルデータのサイズを、このデータサイズでのデータ転送速度を調査するべくバッファにセットする。ステップS604では、ホストは、書き込み、つまりアクセラレータ装置内の空のカーネル・プログラムまたはアプリケーション・カーネル・プログラムを呼び出すための操作コマンドを振り分けて、ステップS605で、所定の繰り返し回数(NUM_ITER)の計算を実行させる。
【0041】
ステップS606で、所定の繰り返し回数(NUM_ITER)が実行された後(yes)は、ホストは、アクセラレータ装置に投入したすべてのイベントの完了が確認されるまで、終了したか否かを判定する。ステップS606は、パラメータ(NUM_ITER)で規定される回数だけステップS604およびステップS605の処理を繰り返すことによって、転送速度および計算速度のより精密な値を得るように繰り返されても良い。また用語「イベント」は、ここでは、転送速度および/または計算速度を決定するために用いられる、グローバル・バッファへのデータ書き込みの単位トランザクションおよび後続するカーネル・プログラムの実行として定義される。すべてのイベントが完了すると、ホストは、ステップS607で、タイマ・オブジェクトを停止させ、ステップS608で、タイマ・オブジェクトのタイマー値(Timer_Value)を経過時間のパラメータ(elapsedTime1またはelapsedTime2)に設定する。いずれのパラメータに設定されるかは、測定が、転送速度のみを目的とするか、転送速度および計算速度の両方を目的とするかに依存する。2種類の測定が異なる種類のパラメータをセットするが、ソフトウェア・モジュールは2つの測定間で共有されてもよい。
【0042】
次にステップS609では、ホストは、サンプルデータのサイズが最大サイズ(MAX_SIZE)に達したかを判定し、サンプルデータが最大サイズ(MAX_SIZE)に達していない場合(no)は、ステップS602に処理が戻され、サンプルデータのサイズが最大サイズ(MAX_SIZE)に達するまで繰り返し実行する。一方、ステップS609の判定で肯定的な結果が返された場合(yes)は、ステップS610で処理を終了させて、性能分析を終了する。パラメータelapsedTime1は、空のカーネル・プログラムが呼び出されたときの全実行時間に相当し、パラメータelapsedTime2は、サンプル計算のために、アクセラレータ装置からアプリケーション・カーネル・プログラムが呼び出されたときの全実行時間に相当する。空のカーネル・プログラムは、データ転送に要する時間のみを得るべく、何も計算を行わずに単純にホスト・アプリケーションから入力データを受信すると直ちにアクノレッジを返すものである。一方で、アプリケーション・カーネル・プログラムは、入力データを用いてアプリケーションで要求された計算を実行し、カーネル計算の完了によりアクノレッジを返すものである。
【0043】
非結合型の計算について経路h2aにおける転送速度は、最小サイズ(MIN_SIZE)および最大サイズ(MAX_SIZE)間のサイズのサンプルデータを用いて空のカーネル・プログラムを呼び出すことによって概算することができ、最適なチャンクサイズは、最もデータ転送速度が速いデータサイズに決定することができる。
【0044】
図7は、
図5(ステップS500)においてアクセラレータ装置からホストへの経路(以下、経路a2hとも参照する)についてのデータ転送コストおよび計算コストを性能分析する詳細な処理を示す。経路a2hの転送速度は、アクセラレータからのホストのデータ読み出し速度によって性能分析することができる。本質的に処理は、
図6に示した処理と大部分において類似するので、ここでは、詳細な説明は省略する。
【0045】
本実施形態によれば、データ転送速度(transferRate)、計算速度(computationRate)および重なり比(overlappingRatio)といったパラメータは、性能分析の結果から得られ、以下のように定義される:
transfeRate = dataSize * NUM_ITER / elapsedTime1
computationRate = dataSize * NUM_ITER / (elapsedTime2- elapsedTime1)
overlappingRatio = transfeRate / computationRate
ここで、データサイズと繰り返し回数との積(dataSize*NUM_ITER)は、パラメータ(elapsedTime1またはelapsedTime2)の測定中に転送されたデータの総量である。
【0046】
より一般的には、最適なデータサイズは、可能なデータサイズの中で最も速い転送速度を与えながら、値|1−overlappingRatio|が閾値を超えないという条件を満たすデータサイズになるように決定することができる。上記閾値は、転送速度(transferRate)および計算速度(computationRate)の取り得る範囲にわたり、その重なりの要件を考慮して、可能な限りゼロ(0)に近い値となるように決定することができる。
【0047】
図8は、転送速度(transferRate)800、計算速度(computationRate)810およびデータサイズの典型的な関係を示す図である。転送速度(transferRate)は、データサイズが小さな場合およびデータサイズが大きい場合の両端において、比較的高いTCP/IPランタイム・オーバヘッドに起因して、低い値となり、したがって、そのプロファイルは、典型的には、データサイズの中間点で最大の転送速度を示す凸形状を有するようになっている。
【0048】
一方、計算速度(computationRate)は、アプリケーション・カーネル・プログラムのオーバヘッドが増加することに起因して、典型的には、データサイズが増加するにつれ減少する。データサイズの範囲にわたって計算速度(computationRate)が転送速度(transferRate)よりも高いケースでは、これは従来のネットワーク通信インフラ基盤に典型的なケースであるかもしれないが、交点が存在せず、最適なチャンクサイズは、凸曲線の最大値840のデータサイズに一意に決定することで、上記定義した最大の重なり比(overlappingRatio)を達成することができる。
【0049】
続いて、転送速度(transferRate)および計算速度(computationRate)が拮抗する場合は、これは近年のギガビット・イーサネット(登録商標)ネットワーク通信または光通信で起こりうるが、
図8に示すように、重なり比(overlappingRatio)が1に可能な限り近接するという条件を満たす複数の交点が存在する。本発明によれば、交点が複数存在する場合は、より高い転送速度(transferRate)を有するデータサイズが最適なチャンクサイズとして採用される。
【0050】
上記決定されたデータサイズは、疎結合型分散計算システムにおいてデータ転送速度および計算速度を最適化する。上述までは、性能分析処理および最適なチャンクサイズの決定について説明した。以下、本発明における効率的な並列計算のためのデータ処理について説明する。
【0051】
図9は、データがアクセラレータ装置に転送されたときのデータ処理を示す。
図9に示す実施形態においては、疑似コード900に示すように、データ・バッファおよびサブバッファが、それぞれアプリケーション・データサイズおよび最適なチャンクサイズに基づいて割り当てられる。典型的な実施形態としてn=2を仮定したアプリケーション・データ910で示すように、ホスト上のアプリケーション・データサイズが所定の数とチャンクサイズとの積(n*chunk size)より大きい場合は、アプリケーション・データは、アクセラレータ装置上のサブバッファに対応して、最適なチャンクサイズを有するn個のチャンクに分割される。典型的な実施形態としてn=2を仮定したアプリケーション・データ920で示すように、ホスト上のアプリケーション・データサイズが、チャンクサイズを所定数で割った値(chunk size/n)より小さい場合は、少なくともn個のアプリケーション・データが1つの最適なチャンクサイズを有するチャンクに集約される。
【0052】
その後、最適なチャンクサイズを有するデータは、アクセラレータ装置に転送される。
図10は、アプリケーション・データサイズが最適なチャンクのサイズよりも大きい場合のデータ転送操作を表す。
図10に示す疑似コード1000は、OpenCL言語での特定の実施形態を記述し、行10では、ホストは、アプリケーション・データのデータサイズ(dataSize)がチャンクサイズの2倍(chunkSize*2)より大きいか否かを判定する。データサイズ(dataSize)がチャンクサイズの2倍(chunkSize*2)より大きい場合は、ホストは、行20で、サブチャンクの数を決定する。ここで、変数「dataSize」は、ホストからアクセラレータ装置へ転送すべきアプリケーション・データのサイズであり、変数「chunkSize」は、転送されるデータをカプセル化するのに最適なチャンクのサイズである。
【0053】
続いて、行30−70で、ホストは、ホストメモリ1010内のアプリケーション・データすべてがアクセラレータ装置のサブバッファ[i]1020へ転送されるまで、アプリケーション・データをチャンクサイズに分割して転送する。ホストメモリ内のアプリケーション・データが最適なチャンクサイズよりも小さい場合のデータ集約にも同様のデータ処理が適用される。
【0054】
図11は、アクセラレータ装置に転送される際にアプリケーション・データが集約される場合のホストおよびアクセラレータ装置のデータ処理を示す。ホストは、ステップS1100で、ホストメモリ1内のデータおよびホストメモリ2内のデータに対し特定の演算を実行して、アプリケーション・データが最適なチャンクサイズの2分の1より小さくなるようにする。ここでは、ステップS1110で示すように、変数numが2に設定されている。続いてステップS1120では、ホストは、アプリケーション・データを最適なサイズのチャンクに集約ないしカプセル化する。そして、ホストは、最適なサイズのチャンクにカプセル化されたアプリケーション・データをアクセラレータ装置に転送する。
【0055】
ステップS1130では、アクセラレータ装置は、アプリケーション・データをホストから受信すると、アプリケーション・データをアクセラレータ装置内の集約された数に対応するバッファに格納する。アクセラレータ装置は、ステップS1140およびS1150で、アプリケーション・カーネル・プログラムを呼び出して、アクセラレータ装置バッファ1内のデータおよびアクセラレータ装置バッファ2内のデータへのカーネル演算を開始する。
【0056】
図12は、従来技術のカーネル計算1210および本発明での結合可能型の演算に対するカーネル計算1220を実行するためのホストの疑似コードを表す。従来技術の処理1210においては、アプリケーション・データは、ホストによって準備されたアプリケーション・データそのままのデータサイズで転送され、アクセラレータ装置は、そのデータを一度に受信する。そしてアクセラレータ装置は、アプリケーション・カーネル/プログラムを呼び出して、カーネル演算を完了させる。
【0057】
代わりに、本発明の実施形態によれば、疑似コード1220で示されるように、アプリケーション・データが最適なチャンクサイズで転送され、アクセラレータ装置は、計算が結合可能型である場合には、各チャンクを受信すると、アプリケーション・カーネル・プログラムを呼び出して、データへの操作を開始する。最後に、アクセラレータ装置は、結合演算を呼び出して、個々のチャンクについて得られた結果を結合する。本処理においては、アクセラレータ装置は、TCP/IPネットワークを経由したデータ転送を最適化するとともに、アプリケーション・データへパイプライン計算を適用することによって、アプリケーション・データに対する全実行時間をさらに削減する。
【0058】
図13は、従来技術の計算効率と比較して、結合可能計算の場合の本発明のパイプライン計算における改善の仕組みを示す。従来技術の計算1300では、ホストで準備されたアプリケーション・データは、そのままのアプリケーション・データサイズでアクセラレータ装置に転送される。すなわち、最適化されずに用意されたアプリケーション・データがアクセラレータ装置に転送されるのである。
【0059】
ブロック1310に示すように、アプリケーション・データが最適なサイズで転送される場合、データ転送効率は、本発明に従って改善され得る。しかしながら、ブロック1320に示すように、カーネル計算がアプリケーション・データの全体を受信した後に呼び出される場合は、アクセラレータ装置でパイプライン計算が適用されないため、アクセラレータ装置は、実質的には、アプリケーション・データが揃うまで計算リソースを浪費することになる。この場合は、アクセラレータ装置におけるアプリケーション・データに対する計算は、時間(Time1)で終了する。
【0060】
本発明においては、ホストは、ブロック1330において示すように、最適なチャンクサイズを有するチャンク内にアプリケーション・データを生成する。そして、カーネル計算が結合可能型であれば、パイプライン計算の命令が投入され、アクセラレータ装置は、あるデータチャンクを受信すると直ちにアプリケーション・カーネル・プログラムを呼び出して、そのチャンクに対するパイプライン計算を開始させる。アクセラレータ装置がすべてのデータチャンクに対する計算を完了させると、アクセラレータ装置は、個々のデータチャンクに対する部分結果を結合するタスクを呼び出し、時間(Time2)で、アクセラレータ装置に対して割り当てたタスクを完了させる。
【0061】
カーネル計算がデータチャンクの転送と並列に実行されて、計算時間における浪費が最小化される。ブロック1340に示すように、同一のタスクをパイプライン処理で実行するために必要な時間(Time2)は、パイプライン操作を行わない場合の時間(Time1)よりも明らかに短縮され、本発明は、アクセラレータ装置を用いた疎結合型アーキテクチャにおいて分散計算の効率を著しく向上させることができる。
【0062】
図14は、本発明を用いた実装システムにおける計算性能の改善結果を示す。IBM zEnterprizeプラットフォーム(z196)と、IBM POWER7を実装するブレードサーバとを1Gbpsおよび10Gbpsのイーサネット(登録商標)に接続して疎結合型システムを構築した。
【0063】
SPSS(インターナショナル・ビジネス・マシーンズ・コーポレーションから提供される。例えば、<URL=http://www-01.ibm.com/software/analytics/spss/>を参照されたい)の2ステップ・クラスタリング・アルゴリズムを用いて、OpenCLで実装し、実験を行った。実験は、
図13のブロック1300に示した従来技術の疎結合型システムを含めて、データ分割およびデータ集約の両方について試行した。
【0064】
図14において、左側のグラフは、1Gbpsネットワーク環境における結果を表し、右側のグラフは、10Gbpsネットワーク環境における結果を表す。両方のグラフにおいて、左側のバーは参照用結果であり、右側のバーは、本発明の結果を表す。
図14に示すように、本発明では、データ分割およびデータ集約の両方のケースについて、参照用結果と比較して実行時間の明瞭な低減が確認された。最適なチャンクサイズは、上述した条件で決定され、1Gbpsネットワークについては64Kバイトに決定され、10Gbpsネットワークについては128Kバイトに決定され、これらは、それぞれアプリケーション・データサイズの4Kおよび8Kに対応している。
【0065】
本発明について図面に示した実施形態を参照しながら説明してきた。しかしながら、本発明は、図面に示した実施形態に限定されるものではなく、当業者が導出できる種々の変更または他の実施形態が可能であり、本発明の範囲は、付記する請求項によって定められる。