JP2013242823A

JP2013242823A - 情報処理装置、情報処理方法および制御プログラム

Info

Publication number: JP2013242823A
Application number: JP2012117111A
Authority: JP
Inventors: Kosuke Haruki; 耕祐春木
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2012-05-23
Filing date: 2012-05-23
Publication date: 2013-12-05
Also published as: US20130332666A1; WO2013175843A1

Abstract

【課題】プログラマの意図通りにパフォーマンスを向上させることが可能な情報処理装置、情報処理方法および制御プログラムを提供することである。
【解決手段】実施の形態による情報処理装置は、ＯｐｅｎＣＬによって記述されたコードを実行するように構成された情報処理装置であって、ローカルなスコープを持ち、１つのワークグループ内の全てのワークアイテムから参照可能な第１キャッシュと、グローバルなスコープを持ち、複数のワークグループ内の全てのワークアイテムから参照可能な第２キャッシュと、グローバルなスコープを持ち、複数のワークグループ内の全てのワークアイテムから参照可能なグローバルメモリと、前記第２キャッシュをスクラッチパッドメモリとして参照するコードを実行するように構成された演算部と、を備えることを特徴とする。
【選択図】図３

Description

本発明の実施形態は、情報処理装置、情報処理方法および制御プログラムに関する。

従来、並列コンピューティングのためのフレームワークとして、ＯｐｅｎＣＬ（ＯｐｅｎＣｏｍｐｕｔｉｎｇＬａｎｇｕａｇｅ）が存在する。ＯｐｅｎＣＬは、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）やＧＰＵ（ＧｒａｐｈｉｃｓＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）などの異種のプロセッサを混在させたヘテロジニアス環境でのクロスプラットフォームなフレームワークとして、現在注目されている。

ＯｐｅｎＣＬでは、カーネル内のメモリとして、グローバルメモリ、コンスタントメモリ、ローカルメモリおよびプライベートメモリの４種類が存在する。これらのうち、プライベートメモリは、ワークアイテム内で使用するレジスタであり、各プロセッサに対して接続される。ローカルメモリは、各ワークグループに対して配置されたキャッシュメモリであり、同一ワークグループ内の全てのワークアイテムから読み書きが可能である。グローバルメモリは、全てのワークグループに対して共通に配置されたメモリであり、全ワークグループ内の全ワークアイテムが読み書き可能である。コンスタントメモリは、グローバルメモリ領域として配置されるメモリ領域であり、すべてのワークアイテムから読み込むことができる。

特開２０１１−１３８５０６号公報特開２０１１−６０２７８号公報特表２０１１−５２３１４０号公報

ＯｐｅｎＣＬの仕様では、キャッシュメモリとして、ローカルなスコープを持つスクラッチパッドメモリに加え、グローバルなスコープを持つスクラッチパッドメモリを持つ多段キャッシュ構造のマルチプロセッサシステムにおいても利用することができる。しかしながら、既存のＯｐｅｎＣＬでは、グローバルなスコープを持つスクラッチパッドメモリを明示的に参照するようにプログラミングすることができない。そのため、プログラマの意図通りにスクラッチパッドメモリを指定してパフォーマンスを向上させることができなかった。

そこで本発明の実施形態が解決しようとする課題は、グローバルなスコープを持つスクラッチパッドメモリを明示的に参照することを可能にすることで、プログラマの意図通りにパフォーマンスを向上させることが可能な情報処理装置、情報処理方法および制御プログラムを提供することである。

実施の形態による情報処理装置は、ＯｐｅｎＣＬによって記述されたコードを実行するように構成された情報処理装置であって、ローカルなスコープを持ち、１つのワークグループ内の全てのワークアイテムから参照可能な第１キャッシュと、グローバルなスコープを持ち、複数のワークグループ内の全てのワークアイテムから参照可能な第２キャッシュと、グローバルなスコープを持ち、複数のワークグループ内の全てのワークアイテムから参照可能なグローバルメモリと、前記第２キャッシュをスクラッチパッドメモリとして参照するコードを実行するように構成された演算部と、を備えることを特徴とする。

また、実施の形態による情報処理方法は、ローカルなスコープを持ち、１つのワークグループ内の全てのワークアイテムから参照可能な第１キャッシュと、グローバルなスコープを持ち、複数のワークグループ内の全てのワークアイテムから参照可能な第２キャッシュと、グローバルなスコープを持ち、複数のワークグループ内の全てのワークアイテムから参照可能なグローバルメモリとを備え、ＯｐｅｎＣＬによって記述されたコードを実行可能な情報処理装置が実行する情報処理方法であって、前記第２キャッシュをスクラッチパッドメモリとして参照するコードを実行する工程を含むことを特徴とする。

また、実施の形態による制御プログラムは、ローカルなスコープを持ち、１つのワークグループ内の全てのワークアイテムから参照可能な第１キャッシュと、グローバルなスコープを持ち、複数のワークグループ内の全てのワークアイテムから参照可能な第２キャッシュと、グローバルなスコープを持ち、複数のワークグループ内の全てのワークアイテムから参照可能なグローバルメモリとを備え、ＯｐｅｎＣＬによって記述されたコードを実行可能な情報処理装置を制御するための制御プログラムであって、前記第２キャッシュをスクラッチパッドメモリとして参照するコードを実行するステップを前記情報処理装置に実行させる。

また、実施の形態による情報処理装置は、ＯｐｅｎＣＬによって記述されたコードを実行するように構成された情報処理装置であって、前記コードは、物理的なアロケーションを制限しないローカルなスコープを持つコードと、物理的なアロケーションを前記グローバルメモリとするグローバルなスコープを持つコードとのうち少なくとも１つを含むことを特徴とする。

また、実施の形態による情報処理方法は、ＯｐｅｎＣＬによって記述されたコードを実行する情報処理方法であって、物理的なアロケーションを制限しないローカルなスコープを持つコードと、物理的なアロケーションを前記グローバルメモリとするグローバルなスコープを持つコードとのうち少なくとも１つを含むコードを実行する工程を含むことを特徴とする。

また、実施の形態による制御プログラムは、ＯｐｅｎＣＬによって記述されたコードを実行するように構成された情報処理装置を制御するための制御プログラムであって、物理的なアロケーションを制限しないローカルなスコープを持つコードと、物理的なアロケーションを前記グローバルメモリとするグローバルなスコープを持つコードとのうち少なくとも１つを含むコードを実行するステップを前記情報処理装置に実行させる。

図１は、既存のＯｐｅｎＣＬで規格されるメモリモデル・プロセッサモデルの概略構成を示すブロック図。図２は、図１に示すメモリモデル・プロセッサモデルにおける各演算ユニット上で実行されるタスクの概略構成を示すモデル図。図３は、実施の形態にかかるメモリモデル・プロセッサモデルの概略構成を示すブロック図。図４は、既存のＯｐｅｎＣＬを用いて記述されたコードの一例を示す図。図５は、実施の形態にかかるＯｐｅｎＣＬを用いて記述されたコードの一例を示す図。図６は、既存のＯｐｅｎＣＬを用いて記述されたコードの他の一例を示す図。図７は、実施の形態にかかるＯｐｅｎＣＬを用いて記述されたコードの他の一例を示す図。図８は、ローカルなスコープのスクラッチパッドメモリを５１２ｂｙｔｅ使用する場合のコードを示す図。図９は、図８に示すコードを既存のＯｐｅｎＣＬで解釈した場合のＯｐｅｎＣＬランタイムあるいはＯｐｅｎＣＬコンパイラの振る舞いを示すフローチャート。図１０は、図８に示すコードを実施の形態にかかるＯｐｅｎＣＬで解釈した場合のＯｐｅｎＣＬランタイムあるいはＯｐｅｎＣＬコンパイラの振る舞いを示すフローチャート。図１１は、ローカルなスコープのスクラッチパッドメモリを１２８ｂｙｔｅ使用する場合のコードを示す図。図１２は、ＯｐｅｎＣＬランタイムにモードＣＬ＿ＲＵＮＴＩＭＥ＿ＳＴＲＩＣＴ＿ＭＯＤＥが設定されていた場合の振る舞いを示すフローチャート。図１３は、ＯｐｅｎＣＬランタイムにモードＣＬ＿ＲＵＮＴＩＭＥ＿ＮＯＲＭＡＬ＿ＭＯＤＥが設定されていた場合の振る舞いを示すフローチャート。

以下、実施の形態にかかる情報処理装置、情報処理方法および制御プログラムを説明するにあたり、既存のＯｐｅｎＣＬで規格されるメモリモデル・プロセッサモデルについて説明する。ＯｐｅｎＣＬ規格は、ＧＰＵなどの並列演算可能なプロセッサを汎用演算器として利用するソフトウエアプラットフォームである。図１は、既存のＯｐｅｎＣＬで規格されるメモリモデル・プロセッサモデル９００の概略構成を示すブロック図である。

図１に示すように、メモリモデル・プロセッサモデル９００は、演算装置９１０がグローバルメモリ２０を介して拡張バス３０に接続された構成を備える。演算装置９１０は、たとえばＣＰＵやＧＰＵなどであってよい。グローバルメモリ２０には、ＶＲＡＭ（ＶｉｄｅｏＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）などを用いることができる。拡張バス３０には、たとえばＰＣＩｅ（ＰＣＩＥｘｐｒｅｓｓ）などのＩ／Ｏシリアルインタフェースが用いられる。

演算装置９１０は、複数の演算ユニット１００〜２００と、各演算ユニット１００〜２００に一対一に設けられたローカルメモリ（Ｌ１キャッシュ）１３０〜２３０と、全ての演算ユニット１００〜２００に対して共通に設けられたグローバルキャッシュ（Ｌ２キャッシュ）９４０とを備える。

各演算ユニット１００〜２００は、それぞれプライベートメモリ１１１〜１１２、２１１〜２１２を一対一に備える複数のプロセッサ１２１〜１２２、２２１〜２２２が並列に配置された構成を備える。プライベートメモリ１１１〜１１２、２１１〜２１２は、それぞれが接続されたプロセッサ１２１〜１２２、２２１〜２２２に対して命令や情報を格納するレジスタである。

演算装置９１０内の各ローカルメモリ１３０〜２３０は、Ｌ１キャッシュ（１次キャッシュともいう）である。一方、グローバルキャッシュ９４０は、Ｌ２キャッシュ（２次キャッシュともいう）である。すなわち、図１に示すメモリモデル・プロセッサモデル９００では、Ｌ１キャッシュとＬ２キャッシュとの多段キャッシュ構造が採用されている。

各ローカルメモリ１３０〜２３０は、それぞれが接続された演算ユニット１００〜２００において実行されるワークグループ内の全てのワークアイテムから読み書きが可能である。ただし、各演算ユニット１００〜２００におけるワークアイテムは、他の演算ユニット１００〜２００に接続されたローカルメモリ１３０〜２３０を参照することができない。一方、グローバルキャッシュ９４０は、全ての演算ユニット１００〜２００において実行されるワークグループ内の全てのワークアイテムから読み書きが可能である。

グローバルメモリ２０は、全ての演算ユニット１００〜２００において実行されるワークグループ内の全てのワークアイテムから読み書きが可能なメモリである。このグローバルメモリ２０は、たとえばコンスタントメモリに置き換えられてもよい。

図２は、図１に示すメモリモデル・プロセッサモデル９００における各演算ユニット１００〜２００上で実行されるタスクの概略構成を示すモデル図である。図２に示すように、演算ユニット１００〜２００のうちの１つの演算ユニット（ここでは、演算ユニット１００とする）上では、ワークグループの集合３００のうちの１つのワークグループ３１０が実行される。各ワークグループ３１０は、複数のワークアイテム（ｗｏｒｋ−ｉｔｅｍ）３１１〜３ｍｎの集合で形成されている。演算ユニット１００内の物理的なプロセッサ数よりもワークグループ３１０内のワークアイテム３１１〜３ｍｎの数が多い場合、各ワークアイテム３１１〜３ｍｎは、演算ユニット１００内でスケジューリングされながら実行される。

通常のＧＰＵでは、ローカルメモリ１３０〜２３０として演算ユニット１００〜２００にそれぞれ接続されたＬ１キャッシュが流用され、且つ、グローバルメモリ２０にＶＲＡＭが用いられるアーキテクチャが採用されている。このような構成では、それぞれのメモリ（１３０〜２３０、２０）へのアクセス速度がＬ１キャッシュへのアクセス速度およびＶＲＡＭへのアクセス速度に相当することとなる。そのため、ＯｐｅｎＣＬで記述されたプログラム（以下、ＯｐｅｎＣＬプログラムという）のパフォーマンスを向上させるためには、ローカルメモリ１３０〜２３０を多く利用してグローバルメモリ２０へのアクセスを減らすようなコードを記述することが定石とされていた。

一方で、ローカルメモリ１３０〜２３０の搭載量は、一般的に少なく、また、搭載されるメモリ容量もデバイスベンダの仕様によって異なる。上述したように、ＯｐｅｎＣＬプログラムのパフォーマンスを向上させるためにはローカルメモリ１３０〜２３０の搭載量を考慮した上でコードを記述する必要があるが、ＯｐｅｎＣＬプログラムが動作するか否かは必要な量のローカルメモリ１３０〜２３０が搭載されているか否かに依存する。そのため、クロスプラットフォームなＯｐｅｎＣＬで記述されたコードであるにも関わらず、他のデバイスでは動作しないコードとなる場合があった。その場合、ハードウエア（ＨＷ）のメモリ搭載量に応じて論理的なスコープを変更しなければならない場合が存在した。

以上のような課題は、ＯｐｅｎＣＬでのローカルメモリの意味が、ワークグループ内のみで参照可能とする論理的な意味と、演算ユニットに付随する物理的な意味との２つの意味を混在して含んでいたために生じたと考えられる。

また、既存のＯｐｅｎＣＬの仕様では、Ｌ１キャッシュ相当（あるいは専用メモリ）をスクラッチパッドメモリとして利用するためのローカルメモリというメモリモデルは存在するものの、Ｌ２キャッシュ相当をスクラッチパッドメモリとして明示的に利用するためのメモリモデルが存在しない。そのため、現状のＯｐｅｎＣＬでは、全てのワークグループ３１０間でデータを共有する場合、必然的にアクセス速度が比較的遅いグローバルメモリ２０を経由しなければならないという課題も存在する。

Ｌ２キャッシュが比較的多く搭載されているデバイスでは、ある程度のデータがＬ２キャッシュにキャッシュされるため、平均的にはある程度のパフォーマンスを得られる場合があるが、動作状況によってはキャッシュミスなどが発生してしまい、パフォーマンスが不安定になる場合があった。

以上のような状況から、本発明者は、安定して高いパフォーマンスを得るためには、Ｌ２キャッシュ相当のメモリをローカルメモリと同様に明示的に利用できる仕組みが必要であることを見出した。そこで、以下の実施の形態では、ＯｐｅｎＣＬへ追加する新たな仕様を提案する。

図３は、実施の形態にかかるメモリモデル・プロセッサモデル１の概略構成を示すブロック図である。なお、図３において、図１に示す構成と同様の構成については、同一の符号を付すことで、重複する説明を省略する。

図３に示すように、実施の形態にかかるメモリモデル・プロセッサモデル１では、演算装置１０が備える各ローカルメモリ１３０〜２３０内に、Ｌ１キャッシュとしてのローカルシェア１３１〜２３１が配置される。また、Ｌ２キャッシュとしてのグローバルキャッシュ９４０が、Ｌ２キャッシュとしてのグローバルシェア１４０に置き換えられている。すなわち、実施の形態にかかるＯｐｅｎＣＬでは、Ｌ１キャッシュ相当のローカルシェア１３１〜２３１と、Ｌ２キャッシュ相当のグローバルシェア１４０との２つのメモリモデルを新たに追加し、これらローカルシェア１３１〜２３１およびグローバルシェア１４０を明示的に利用できるキャッシュメモリであるとして定義する。その他の構成は、図１に示す構成と同様であってよい。

以下の表１に、実施の形態にかかるＯｐｅｎＣＬで記述可能なメモリ修飾子の一覧を示す。なお、表１には、既存のＯｐｅｎＣＬで記述可能なローカルスコープおよびグローバルスコープの修飾子と、実施の形態にかかるＯｐｅｎＣＬで記述可能なローカルスコープおよびグローバルスコープの修飾子とが示されている。

表１に示すように、既存のＯｐｅｎＣＬでは、メモリ修飾子が、ローカルメモリ１３０〜２３０を示す修飾子‘＿ｌｏｃａｌ’とグローバルメモリ２０を示す修飾子‘＿ｇｌｏｂａｌ’との２つのみであったのに対し、実施の形態にかかるＯｐｅｎＣＬでは、Ｌ１キャッシュに相当するローカルシェア１３１〜２３１を示す修飾子‘＿ｌｏｃａｌ＿ｓｈａｒｅ’と、Ｌ２キャッシュに相当するグローバルシェア１４０を示す修飾子‘＿ｇｌｏｂａｌ＿ｓｈａｒｅ’とが追加されている。また、これら２つの修飾子の追加に伴い、既存のＯｐｅｎＣＬにおける修飾子‘＿ｌｏｃａｌ’の意味が表１に示す内容に変更された。

具体的には、追加された修飾子‘＿ｌｏｃａｌ＿ｓｈａｒｅ’は、ローカルなスコープのスクラッチパッドメモリ（Ｌ１キャッシュ相当）を定義する。同じく追加された修飾子‘＿ｇｌｏｂａｌ＿ｓｈａｒｅ’は、グローバルなスコープのスクラッチパッドメモリ（Ｌ２キャッシュ相当）を定義する。また、定義が変更された修飾子‘＿ｌｏｃａｌ’は、物理的なアロケーションを制限せずに、論理的なスコープのみを規定する。したがって、図３に示す構成の場合、修飾子‘＿ｌｏｃａｌ’によって宣言されたコードが示す物理的なアロケーションは、ローカルメモリ１３０〜２３０、グローバルシェア１４０およびグローバルメモリ２０のいずれであってもよい。

また、修飾子‘＿ｇｌｏｂａｌ＿ｓｈａｒｅ’で指定されるバッファオブジェクトをグローバルシェア（Ｌ２キャッシュ）１４０に確保するためのフラグとして、以下の表２に示すような値‘ＣＬ＿ＭＥＭ＿ＧＬＯＢＡＬ＿ＳＨＡＲＥ’が追加される。この値‘ＣＬ＿ＭＥＭ＿ＧＬＯＢＡＬ＿ＳＨＡＲＥ’は、構文ｃｌＣｒｅａｔｅＢｕｆｆｅｒ（）の引数‘ｃｌ＿ｍｅｍ＿ｆｌａｇｓ’に指定される。

また、ＯｐｅｎＣＬランタイムのモードあるいはＯｐｅｎＣＬコンパイラのモードとして、以下の表３に示す２つが定義される。これらのモードは、ローカルシェア１３１〜２３１およびグローバルシェア１４０に対するＯｐｅｎＣＬランタイムの振る舞いを規定するものであり、構文ｃｌ＿ｒｕｎｔｉｍｅ＿ｍｏｄｅの引数‘ｃｌ＿ｒｕｎｔｉｍｅ＿ｍｏｄｅ’に指定される。なお、表３に示すモードは、ＯｐｅｎＣＬコンパイラへの指示としても利用することができる。

表１にも示したように、ＯｐｅｎＣＬランタイムにモードＣＬ＿ＲＵＮＴＩＭＥ＿ＮＯＲＭＡＬ＿ＭＯＤＥが指定されているときでは、修飾子‘＿ｌｏｃａｌ＿ｓｈａｒｅ’または‘＿ｇｌｏｂａｌ＿ｓｈａｒｅ’が宣言された際にＬ１キャッシュまたはＬ２キャッシュにメモリが不足しているのであれば、物理的なアロケーションをグローバルメモリ２０としてもよい。

つづいて、実施の形態にかかるＯｐｅｎＣＬを用いて記述されたコードを、既存のＯｐｅｎＣＬを用いて記述されたコードと比較しつつ説明する。図４および図５は、５１２ｂｙｔｅの配列ａをワークグループ内のみで参照することを意図するが、ハードウエアの制限によって物理的なスクラッチパッドメモリ（Ｌ１キャッシュ相当）に配列ａを配置できない場合のコードを示す図である。なお、図４は、既存のＯｐｅｎＣＬを用いて記述されたコードの一例を示す図である。図５は、実施の形態にかかるＯｐｅｎＣＬを用いて記述されたコードの一例を示す図である。

図４に示すように、既存のＯｐｅｎＣＬでは、配列ａをワークグループ内のスコープとして宣言できないため、グローバルなスコープ（＿ｇｌｏｂａｌａ［］）で宣言する必要があった。そのため、可読性の低いコードとなっていた。それに対し、図５に示すように、実施の形態にかかるＯｐｅｎＣＬでは、論理的なスコープと物理的なスコープとを分離して宣言できるため、プログラマの意図通りに、配列ａをワークグループ内のスコープ（＿ｌｏｃａｌａ［５１２］）で宣言することができる。また、配列ｂを物理的なスクラッチパッドメモリ（Ｌ１キャッシュ相当）に配置したいというプログラマの意図も、修飾子‘＿ｌｏｃａｌ＿ｓｈａｒｅ’を用いて記述することが可能である。

つぎに、図６および図７に、配列ａを全てのワークグループ間で共有して参照したいが、読み書きが頻繁に発生する見込みであるため、高速アクセスが可能な物理アロケーションに配置したい場合のコードを示す。なお、図６は、既存のＯｐｅｎＣＬを用いて記述されたコードの一例を示す図である。図７は、実施の形態にかかるＯｐｅｎＣＬを用いて記述されたコードの一例を示す図である。

図６に示すように、既存のＯｐｅｎＣＬでは、修飾子‘＿ｇｌｏｂａｌ’によるスコープ（＿ｇｌｏｂａｌａ［］）のみでしか物理的なアロケーションを指定することができない。そのため、ハードウエア構成によってはキャッシュが有効に利用されるもののが、動作状況によってはパフォーマンスが低下したり不安定になってしまう場合がある。それに対し、図７に示すように、実施の形態にかかるＯｐｅｎＣＬでは、修飾子‘＿ｇｌｏｂａｌ＿ｓｈａｒｅ’を用いることで、グローバルなスコープで且つ物理的なスクラッチパッドメモリ（Ｌ２キャッシュ相当）を利用するというプログラマの意図（＿ｇｌｏｂａｌ＿ｓｈａｒｅａ［］）を記述することができる。これにより、パフォーマンスの向上だけでなく、パフォーマンスの安定化も可能になる。

つぎに、ローカルなスコープのスクラッチパッドメモリを５１２ｂｙｔｅ使用するコードを、既存のＯｐｅｎＣＬで解釈した場合と実施の形態にかかるＯｐｅｎＣＬで解釈した場合との振る舞いの違いを説明する。図８は、ローカルなスコープのスクラッチパッドメモリを５１２ｂｙｔｅ使用する場合のコードを示す図である。なお、図８に示すコードは、既存のＯｐｅｎＣＬと実施の形態にかかるＯｐｅｎＣＬとで同一である。図９は、図８に示すコードを既存のＯｐｅｎＣＬで解釈した場合のＯｐｅｎＣＬランタイムあるいはＯｐｅｎＣＬコンパイラの振る舞いを示すフローチャートである。図１０は、図８に示すコードを実施の形態にかかるＯｐｅｎＣＬで解釈した場合のＯｐｅｎＣＬランタイムあるいはＯｐｅｎＣＬコンパイラの振る舞いを示すフローチャートである。

図９に示すように、図８に示すコードを既存のＯｐｅｎＣＬで解釈した場合、ＯｐｅｎＣＬランタイムあるいはＯｐｅｎＣＬコンパイラは、まず、ローカルなスコープ（＿ｌｏｃａｌａ［５１２］）で５１２ｂｙｔｅのメモリ領域の要求があると（ステップＳ１０１）、ローカルメモリ１３０内のローカルシェア１３１に５１２ｂｙｔｅのメモリ領域を確保可能か否かを判定する（ステップＳ１０２）。ローカルシェア１３１に要求されたメモリ領域を確保可能である場合（ステップＳ１０２；ＹＥＳ）、ＯｐｅｎＣＬランタイムあるいはＯｐｅｎＣＬコンパイラは、ローカルシェア１３１に要求されたメモリ領域を確保して（ステップＳ１０３）、動作を終了する。また、ローカルシェア１３１に要求されたメモリ領域を確保できない場合（ステップＳ１０２；ＮＯ）、ＯｐｅｎＣＬランタイムあるいはＯｐｅｎＣＬコンパイラは、エラー処理を実行し（ステップＳ１０４）、動作を終了する。なお、エラー処理では、コンパイルができないことや、ローカルシェア１３１に要求されたメモリ領域を確保できないことがプログラマへ通知されてもよい。

一方、図１０に示すように、図８に示すコードを実施の形態にかかるＯｐｅｎＣＬで解釈した場合、ＯｐｅｎＣＬランタイムあるいはＯｐｅｎＣＬコンパイラは、まず、ローカルなスコープ（＿ｌｏｃａｌａ［５１２］）で５１２ｂｙｔｅのメモリ領域の要求があると（ステップＳ１１１）、ローカルシェア１３１に５１２ｂｙｔｅのメモリ領域を確保可能か否かを判定し（ステップＳ１１２）、確保可能である場合（ステップＳ１１２；ＹＥＳ）、ローカルシェア１３１に要求されたメモリ領域を確保して（ステップＳ１１３）、動作を終了する。また、ローカルシェア１３１に要求されたメモリ領域を確保できない場合（ステップＳ１１２；ＮＯ）、ＯｐｅｎＣＬランタイムあるいはＯｐｅｎＣＬコンパイラは、つぎにグローバルシェア１４０に要求されたメモリ領域を確保可能か否かを判定し（ステップＳ１１４）、確保可能である場合（ステップＳ１１４；ＹＥＳ）、グローバルシェア１４０に要求されたメモリ領域を確保して（ステップＳ１１５）、動作を終了する。さらに、グローバルシェア１４０にも要求されたメモリを確保できない場合（ステップＳ１１４；ＮＯ）、ＯｐｅｎＣＬランタイムあるいはＯｐｅｎＣＬコンパイラは、グローバルメモリ２０に要求されたメモリ領域を確保可能か否かを判定し（ステップＳ１１６）、確保可能である場合（ステップＳ１１６；ＹＥＳ）、グローバルメモリ２０に要求されたメモリ領域を確保して（ステップＳ１１７）、動作を終了する。さらにまた、グローバルメモリ２０にも要求されたメモリ領域を確保できない場合（ステップＳ１１６；ＮＯ）、ＯｐｅｎＣＬランタイムあるいはＯｐｅｎＣＬコンパイラは、エラー処理を実行し（ステップＳ１１８）、動作を終了する。

以上のように、実施の形態では、ローカルなスコープ（＿ｌｏｃａｌａ［５１２］）で指定される物理的なアロケーションが制限されないため、要求されたメモリ領域をローカルシェア（Ｌ１キャッシュ）１３１に確保できない場合でも、代わりに他の物理アロケーション（グローバルシェア１４０やグローバルメモリ２０）に確保することが可能となる。その結果、多くのデバイスで互換性のあるコードを記述することが可能となる。

つぎに、ローカルなスコープのスクラッチパッドメモリを１２８ｂｙｔｅ使用する場合の、ＯｐｅｎＣＬランタイムのモード毎の振る舞いの違いを説明する。図１１は、ローカルなスコープのスクラッチパッドメモリを１２８ｂｙｔｅ使用する場合のコードを示す図である。図１２は、ＯｐｅｎＣＬランタイムにモードＣＬ＿ＲＵＮＴＩＭＥ＿ＳＴＲＩＣＴ＿ＭＯＤＥが設定されていた場合の振る舞いを示すフローチャートである。図１３は、ＯｐｅｎＣＬランタイムにモードＣＬ＿ＲＵＮＴＩＭＥ＿ＮＯＲＭＡＬ＿ＭＯＤＥが設定されていた場合の振る舞いを示すフローチャートである。

図１２に示すように、ＯｐｅｎＣＬランタイムにモードＣＬ＿ＲＵＮＴＩＭＥ＿ＳＴＲＩＣＴ＿ＭＯＤＥが設定されていた場合、図１１に示すコードを解釈したＯｐｅｎＣＬランタイムあるいはＯｐｅｎＣＬコンパイラは、まず、ローカルなスコープ（＿ｌｏｃａｌ＿ｓｈａｒｅａ［１２８］）で１２８ｂｙｔｅのメモリ領域の要求があると（ステップＳ２０１）、ローカルメモリ１３０内のローカルシェア１３１に１２８ｂｙｔｅのメモリ領域を確保可能か否かを判定する（ステップＳ２０２）。ローカルシェア１３１に要求されたメモリ領域を確保可能である場合（ステップＳ２０２；ＹＥＳ）、ＯｐｅｎＣＬランタイムあるいはＯｐｅｎＣＬコンパイラは、ローカルシェア１３１に要求されたメモリ領域を確保して（ステップＳ２０３）、動作を終了する。また、ローカルシェア１３１に要求されたメモリ領域を確保できない場合（ステップＳ２０２；ＮＯ）、ＯｐｅｎＣＬランタイムあるいはＯｐｅｎＣＬコンパイラは、エラー処理を実行し（ステップＳ２０４）、動作を終了する。

一方、図１３に示すように、ＯｐｅｎＣＬランタイムにモードＣＬ＿ＲＵＮＴＩＭＥ＿ＮＯＲＭＡＬ＿ＭＯＤＥが設定されていた場合、図１１に示すコードを解釈したＯｐｅｎＣＬランタイムあるいはＯｐｅｎＣＬコンパイラは、まず、ローカルなスコープ（＿ｌｏｃａｌ＿ｓｈａｒｅａ［１２８］）で１２８ｂｙｔｅのメモリ領域の要求があると（ステップＳ２１１）、ローカルシェア１３１に１２８ｂｙｔｅのメモリ領域を確保可能か否かを判定し（ステップＳ２１２）、確保可能である場合（ステップＳ２１２；ＹＥＳ）、ローカルシェア１３１に要求されたメモリ領域を確保して（ステップＳ２１３）、動作を終了する。また、ローカルシェア１３１に要求されたメモリ領域を確保できない場合（ステップＳ２１２；ＮＯ）、ＯｐｅｎＣＬランタイムあるいはＯｐｅｎＣＬコンパイラは、つぎにグローバルシェア１４０に要求されたメモリ領域を確保可能か否かを判定し（ステップＳ２１４）、確保可能である場合（ステップＳ２１４；ＹＥＳ）、グローバルシェア１４０に要求されたメモリ領域を確保して（ステップＳ２１５）、動作を終了する。さらに、グローバルシェア１４０にも要求されたメモリを確保できない場合（ステップＳ２１４；ＮＯ）、ＯｐｅｎＣＬランタイムあるいはＯｐｅｎＣＬコンパイラは、グローバルメモリ２０に要求されたメモリ領域を確保可能か否かを判定し（ステップＳ２１６）、確保可能である場合（ステップＳ２１６；ＹＥＳ）、グローバルメモリ２０に要求されたメモリ領域を確保して（ステップＳ２１７）、動作を終了する。さらにまた、グローバルメモリ２０にも要求されたメモリ領域を確保できない場合（ステップＳ２１６；ＮＯ）、ＯｐｅｎＣＬランタイムあるいはＯｐｅｎＣＬコンパイラは、エラー処理を実行し（ステップＳ２１８）、動作を終了する。

以上のように、実施の形態では、ＯｐｅｎＣＬランタイムに設定されたモードにしたがって振る舞いを切り替えることが可能である。たとえば図１１〜図１３に示した例では、ローカルなスコープ（＿ｌｏｃａｌ＿ｓｈａｒｅａ［１２８］）で指定される物理的なアロケーションに必要なメモリ領域を確保できない場合の振る舞いを、ＯｐｅｎＣＬランタイムに設定されたモードに応じて変更することができる。この機能は、プログラマによるデバッグやパフォーマンスチューニングにおいて有効である。

以上のように、実施の形態では、Ｌ１キャッシュとＬ２キャッシュとの多段キャッシュを備えるメモリモデル・プロセッサモデル１において、これらのキャッシュメモリを明示的に利用することが可能なコードのＯｐｅｎＣＬプログラムを記述することができる。また、実施の形態では、ＯｐｅｎＣＬで提示されている論理的なメモリモデルに由来する変数のスコープと、実際のハードウエアに依存した物理的にアロケーション可能なメモリ量とを分離しつつ、ＯｐｅｎＣＬプログラムを記述することができる。これらの結果、実施の形態によれば、物理的なメモリ搭載量に関わらず、動作が保証されたＯｐｅｎＣＬプログラムを記述することが可能となる。加えて、異なるハードウエアに対しても互換性の高いＯｐｅｎＣＬプログラムを記述することも可能となる。

また、実施の形態にかかるＯｐｅｎＣＬによれば、ハードウエア構成に応じたＯｐｅｎＣＬプログラムを容易に記述することが可能となるため、特定のハードウエアがより高いパフォーマンスを発揮することできるＯｐｅｎＣＬプログラムを記述することも可能になる。

さらに、実施の形態によれば、ワークグループ内という論理的なスコープのみが必要で、必ずしも高いパフォーマンスを必要としないコードを記述した場合でも、このようなプログラマの意図通りにスコープを限定した記述が可能である。その結果、プログラムの可読性や開発効率を向上させることができる。

以上では、本発明の実施形態を説明したが、この実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。この新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。この実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１…メモリモデル・プロセッサモデル、１０…演算装置、２０…グローバルメモリ（ＶＲＡＭ）、３０…拡張バス、１００〜２００…演算ユニット、１１１〜１１２，２１１〜２１２…プライベートメモリ（レジスタ）、１２１〜１２２，２２１〜２２２…プロセッサ、１３０〜２３０…ローカルメモリ、１３１〜２３１…ローカルシェア（Ｌ１キャッシュ）、１４０…グローバルシェア（Ｌ２キャッシュ）

Claims

ＯｐｅｎＣＬによって記述されたコードを実行するように構成された情報処理装置であって、
ローカルなスコープを持ち、１つのワークグループ内の全てのワークアイテムから参照可能な第１キャッシュと、
グローバルなスコープを持ち、複数のワークグループ内の全てのワークアイテムから参照可能な第２キャッシュと、
グローバルなスコープを持ち、複数のワークグループ内の全てのワークアイテムから参照可能なグローバルメモリと、
前記第２キャッシュをスクラッチパッドメモリとして参照するコードを実行するように構成された演算部と、
を備えることを特徴とする情報処理装置。
前記コードは、前記第１キャッシュと前記第２キャッシュとをそれぞれ異なるスクラッチパッドメモリとして区別して参照するように記述され、
前記演算部は、前記コードに基づいて、前記第１キャッシュと前記第２キャッシュとをそれぞれ異なるスクラッチパッドメモリとして区別して参照することを特徴とする請求項１に記載の情報処理装置。
前記コードは、前記第１キャッシュをスクラッチパッドメモリとして参照するローカルなスコープを持つ第１コードと、前記第２キャッシュをスクラッチパッドメモリとして参照するグローバルなスコープを持つ第２コードとのうち少なくとも１つを含むことを特徴とする請求項２に記載の情報処理装置。
前記演算部は、前記コードにより要求されるメモリ領域が前記第２キャッシュに確保できない場合、前記第１キャッシュまたは前記グローバルメモリに前記要求されたメモリ領域を確保することを特徴とする請求項１に記載の情報処理装置。
ＯｐｅｎＣＬランタイムのモードとして第１モードと第２モードとを備え、
前記演算部は、前記第１モードが設定されているときであって前記コードにより要求されるメモリ領域を前記第２キャッシュに確保できない場合、前記第１キャッシュまたは前記グローバルメモリに前記要求されたメモリ領域を確保し、前記第２モードが設定されているときであって前記コードにより要求されるメモリ領域を前記第２キャッシュに確保できない場合、エラーとすることを特徴とする請求項４に記載の情報処理装置。
前記グローバルメモリの物理的なアロケーションは、ＶＲＡＭであることを特徴とする請求項１に記載の情報処理装置。
ローカルなスコープを持ち、１つのワークグループ内の全てのワークアイテムから参照可能な第１キャッシュと、グローバルなスコープを持ち、複数のワークグループ内の全てのワークアイテムから参照可能な第２キャッシュと、グローバルなスコープを持ち、複数のワークグループ内の全てのワークアイテムから参照可能なグローバルメモリとを備え、ＯｐｅｎＣＬによって記述されたコードを実行可能な情報処理装置が実行する情報処理方法であって、
前記第２キャッシュをスクラッチパッドメモリとして参照するコードを実行する工程を含むことを特徴とする情報処理方法。
ローカルなスコープを持ち、１つのワークグループ内の全てのワークアイテムから参照可能な第１キャッシュと、グローバルなスコープを持ち、複数のワークグループ内の全てのワークアイテムから参照可能な第２キャッシュと、グローバルなスコープを持ち、複数のワークグループ内の全てのワークアイテムから参照可能なグローバルメモリとを備え、ＯｐｅｎＣＬによって記述されたコードを実行可能な情報処理装置を制御するための制御プログラムであって、
前記第２キャッシュをスクラッチパッドメモリとして参照するコードを実行するステップを前記情報処理装置に実行させるための制御プログラム。
ＯｐｅｎＣＬによって記述されたコードを実行するように構成された情報処理装置であって、
前記コードは、物理的なアロケーションを制限しないローカルなスコープを持つコードと、物理的なアロケーションを前記グローバルメモリとするグローバルなスコープを持つコードとのうち少なくとも１つを含むことを特徴とする情報処理装置。
ＯｐｅｎＣＬによって記述されたコードを実行する情報処理方法であって、
物理的なアロケーションを制限しないローカルなスコープを持つコードと、物理的なアロケーションを前記グローバルメモリとするグローバルなスコープを持つコードとのうち少なくとも１つを含むコードを実行する工程を含むことを特徴とする情報処理方法。
ＯｐｅｎＣＬによって記述されたコードを実行するように構成された情報処理装置を制御するための制御プログラムであって、
物理的なアロケーションを制限しないローカルなスコープを持つコードと、物理的なアロケーションを前記グローバルメモリとするグローバルなスコープを持つコードとのうち少なくとも１つを含むコードを実行するステップを前記情報処理装置に実行させるための制御プログラム。