WO2014119003A1 - コンパイラ、オブジェクトコード生成方法、情報処理装置及び情報処理方法 - Google Patents

コンパイラ、オブジェクトコード生成方法、情報処理装置及び情報処理方法 Download PDF

Info

Publication number
WO2014119003A1
WO2014119003A1 PCT/JP2013/058157 JP2013058157W WO2014119003A1 WO 2014119003 A1 WO2014119003 A1 WO 2014119003A1 JP 2013058157 W JP2013058157 W JP 2013058157W WO 2014119003 A1 WO2014119003 A1 WO 2014119003A1
Authority
WO
WIPO (PCT)
Prior art keywords
compiler
data
object code
processors
source program
Prior art date
Application number
PCT/JP2013/058157
Other languages
English (en)
French (fr)
Inventor
隆二 境
Original Assignee
株式会社 東芝
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社 東芝 filed Critical 株式会社 東芝
Priority to US14/015,670 priority Critical patent/US20140223419A1/en
Publication of WO2014119003A1 publication Critical patent/WO2014119003A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/45—Exploiting coarse grain parallelism in compilation, i.e. parallelism between groups of instructions
    • G06F8/453—Data distribution

Definitions

  • Embodiments described herein relate generally to a compiler, an object code generation method, an information processing apparatus, and an information processing method.
  • multi-thread processing exists as a program execution model for multi-core.
  • a plurality of threads serving as execution units operate in parallel and perform parallel processing by exchanging data on the main memory.
  • An example of the execution form of the parallel processing is composed of two elements: a runtime process including a scheduler that assigns a plurality of execution units to each execution unit (CPU core), and a thread that operates on each execution unit.
  • a runtime process including a scheduler that assigns a plurality of execution units to each execution unit (CPU core), and a thread that operates on each execution unit.
  • synchronization between threads is important. If synchronization processing is not appropriate, problems such as deadlock and loss of data consistency occur. Therefore, conventionally, the execution order of threads is scheduled, and synchronization between threads is maintained by performing parallel processing based on this schedule.
  • each device such as an accelerator such as GPGPU (General-purpose computing-on graphics-processing-units; technology that applies GPU general-purpose computation, GPU computing resources for purposes other than image processing)
  • GPGPU General-purpose computing-on graphics-processing-units; technology that applies GPU general-purpose computation, GPU computing resources for purposes other than image processing
  • a buffer is used to exchange data between the CPU and the GPU. Define and transfer data to the memory of the calculation side to execute parallel calculation.
  • An object of the embodiment of the present invention is to provide a technique capable of simply implementing a more efficient acceleration calculation program.
  • the compiler is a compiler that is applied to a parallel computer including a plurality of processors, and in the compiler that inputs a source program and generates local code of each of the processors, the input source program is analyzed.
  • FIG. 1 is a diagram illustrating an example of the configuration of the entire system according to the embodiment.
  • FIG. 2 is a functional block configuration diagram showing an example of a system configuration of the embodiment.
  • FIG. 3A is a diagram illustrating an example of the order in which the CPU calls the kernel in the embodiment.
  • FIG. 3B is a diagram for explaining an example of the data flow of the embodiment.
  • FIG. 3C is a diagram for explaining an example of the data processing sequence of the embodiment.
  • FIG. 3D is a diagram illustrating an example of data and kernel types according to the embodiment.
  • FIG. 4 is a diagram for explaining an example of the operation principle of a general compiler.
  • FIG. 5 is a flowchart showing an example of data copy point calculation and copy code insertion according to the embodiment.
  • FIG. 5 is a flowchart showing an example of data copy point calculation and copy code insertion according to the embodiment.
  • FIG. 6A is a diagram illustrating an example of the order in which the CPU calls the kernel in the embodiment.
  • FIG. 6B is a diagram for explaining an example of the data flow of the embodiment.
  • FIG. 6C is a diagram for explaining an example of the data processing sequence of the embodiment.
  • FIG. 6D is a diagram illustrating an example of the data structure of the buffer view according to the embodiment.
  • FIG. 7 is a diagram illustrating another example of the configuration of the entire system according to the embodiment.
  • FIG. 8 is a functional block configuration diagram showing an example of a system configuration used in the embodiment.
  • the present embodiment relates to an object code generation method that can be used as an information processing apparatus or an information processing method, and that can be applied to a compiler that inputs a source program and generates local codes of processors constituting a parallel computer.
  • the code generation method makes it possible to generate local code independent of the processor structure.
  • FIG. 1 shows an example of the overall system configuration of the embodiment.
  • a computing device 10 (hereinafter also referred to as a GPU) that is a GPU or the like is controlled by the host CPU 12.
  • the computing device 10 includes a multi-core processor and is divided into a large number of core blocks. In the example of FIG. 1, the computing device 10 is divided into eight core blocks 34.
  • the computing device 10 can manage another context for each core block 34.
  • the core block consists of 16 cores. By operating core blocks or cores in parallel, high-speed task parallel processing becomes possible.
  • the core block 34 is identified by a block ID.
  • the block ID is 0-7.
  • the 16 cores in the block are identified by a local ID, and the local ID is 0-15.
  • a core having a local ID of 0 is referred to as a block representative core 32.
  • the host CPU 12 may also be a multi-core processor. In the example of FIG. 1, a dual core processor is assumed.
  • the host CPU 12 has a three-stage cache memory hierarchy.
  • the L1 cache 22 connected to the main memory 16 is provided in the host CPU 12 and is connected to the L2 caches 26a and 26b.
  • the L2 caches 26a and 26b are connected to the CPU cores 24a and 24b, respectively.
  • the L1 cache 22 and the L2 caches 26a and 26b have a hardware synchronization mechanism, and a synchronization process necessary for accessing the same address is performed.
  • the L2 caches 26a and 26b hold data of addresses referred to in the L1 cache 22, and when a cache miss occurs, a necessary synchronization process is performed with the main memory 16 by a hardware synchronization mechanism. .
  • the device memory 14 that can be accessed by the computing device 10 is connected to the computing device 10, and the main memory 16 is connected to the host CPU 12. Since the two memories of the main memory 16 and the device memory 14 are connected, data is copied (synchronized) between the device memory 14 and the main memory 16 before and after the processing is executed by the computing device 10. For this reason, the main memory 16 and the device memory 14 are connected to each other. When a plurality of processes are executed continuously, there is no need to execute copy for each process.
  • FIG. 2 shows an example of the system function configuration.
  • the computing device 10 is connected to the host CPU 12 via PCIe (PCI Express), and the computing device 10 has a dedicated device memory (consisting of DRAM) 14.
  • the substance of the buffer for storing data used for calculation is allocated to the main memory 16 of the host CPU 12 and the device memory 14 of the calculation device 10, respectively, and the state is managed by a data structure called BufferView.
  • This data structure includes four elements as shown in FIG. If the target data shared by the host CPU 12 and the GPU 10 is data A, Size is the size (number of bytes) of the data A. In addition to the state described below, there are Cpu_mem and Gpu_mem.
  • Cpu_mem is a pointer indicating the position of the data A in the main memory 16
  • Gpu_mem is a pointer indicating the position of the data A in the device memory 14.
  • FIG. 3A shows “the order in which kernel functions are called by the host CPU 12”.
  • FIG. 3A is a kernel call described in the program code.
  • the kernel functions K E , K F , K I , and K J are executed by the host CPU 12, and the kernel functions K G and K H are executed by the GPU 20.
  • the FIG. 3B shows an example of the data flow of the entire process.
  • FIG. 3C shows an example of a data processing sequence.
  • FIG. 3D shows an example of data and kernel types.
  • the state of the running the kernel K E on the host CPU12 BufferView E as shown in FIG. FIGS. 3A-3D are "CPU only” and the kernel K F
  • the kernel K H to run on the GPU is invoked to check BufferView E, the state of F, in order status is "CPU only”, starts the data copy. When copying is completed, the status is changed to “Shared”.
  • BufferView G, H, the kernel K G, K H at the end is a state of "GPU only", since the copy of the first time BufferView G is started when you call the kernel K I, of the kernel K I Execution start is delayed.
  • BufferView G This start copying of BufferView G may start immediately after the end of the kernel K G to solve, but this programming is complicated in, it impairs the convenience of abstraction BufferView.
  • the general configuration of a general compiler to which the object code generation method according to this embodiment is applied includes a compiler, an optimization conversion unit, and a code generation unit.
  • the compiler reads the source program, parses it, converts it into intermediate code, and stores it in the memory. Specifically, the source program is parsed to generate intermediate code, and then optimization, code generation, and object code output are performed. In this optimization, there are a flow of control flow analysis, data dependency analysis, and various optimizations (intermediate code conversion).
  • the analysis of the Def-Use chain described later is a data dependency analysis, and the insertion of the data transfer code is a function realized by various optimization and code generation units.
  • step S22 the compiler reads the source program B25, parses it, and converts the source program B25 into an intermediate format B26 that is an internal representation.
  • step S23 the compiler performs various optimization conversions on the intermediate format (internal representation) B26 to generate a converted intermediate format B27.
  • the compiler scans the intermediate format B27 converted in step S24, and generates an object code B28 for each PE.
  • An example of the operation of the compiler is to generate a machine language code from a C language series program.
  • the data flow is analyzed at the time of program compilation, and a code for starting data copy is inserted only when necessary.
  • the Def-Use chain of BufferView is analyzed, and the code for kicking the data copy is inserted immediately after the Def kernel to be executed only when the execution device of the Def Kernel and the Use Kernel is different.
  • FIG. 3C it is possible to early start the execution of the kernel KI (K from K G in FIG. 3C I, K see dashed from H to K J. K H is shifted from the end to the K I in conventional) can shorten the overall execution time.
  • FIG. 3D lists data and kernel attributes related to the data flow in FIG. 3B.
  • du-chain definition-use chain
  • the problem of the du-chain is to find a set of sentences s using a variable x for a point p. The specific steps are as follows.
  • Step S71 The program is divided into basic blocks.
  • Step S72 A control flow graph is created.
  • Step S73 Analyzing the data flow for BufferView and creating a Def-Use chain.
  • Step S74A It is determined whether or not all BufferView Def-Use chain processes have been executed. If it is determined that the process has been executed, the process loops up to Step S74C, and the entire process ends.
  • Step S74B It is determined whether the kernel execution device that defers BufferView is different from the kernel execution device that uses BufferView. If this determination is Yes, the process proceeds to the next step S74C, and if No, the process returns to step S74A.
  • Step S74C Insert a code for starting data copy immediately after execution of the kernel to be Def.
  • the code for generating the data copy calling process is realized by a function, for example.
  • a basic block consists of a sequence of consecutive sentences, and control is given to the first sentence, and then the control leaves the last sentence without stopping or branching in the middle.
  • a sequence of so-called third address sentences forms a basic block.
  • BlockSize is a value obtained by dividing Size (9000 bytes) into three.
  • FIG. 6A shows an example of the order in which the CPU calls the kernel.
  • FIG. 6B shows an example of the data flow.
  • FIG. 6C shows an example of the data structure of the buffer view.
  • FIG. 6D shows an example of a data processing sequence.
  • FIG. 7 is a diagram showing another example of the system configuration.
  • the computing device 10 and the host CPU 12 share the main memory 16, and a device memory area 14 B equivalent to the device memory 14 of FIG. 1 is provided in the main memory 16. In this case, it is not necessary to copy data between the device memory and the main memory.
  • a memory area 14B is provided with a shared cache 16B interposed.
  • the data copy in the first embodiment is replaced with prefetch to the cache, so that the CPU / GPU / other accelerator is the memory Even in the case of sharing, it is an effective means for improving performance in a simple program description.
  • mem is a pointer indicating the position of the data A in the shared cache 16B.
  • a data transfer calling process is generated by obtaining a data transfer point at the time of program compilation.
  • the input data buffer is subdivided and data is flowed in a stream so that the calculation start timing in the multi-core CPU is advanced, thereby Improve performance.
  • a programmer can create a program that starts copying data at an appropriate timing without describing data transfer processing, so that an efficient acceleration calculation program can be simply implemented. It becomes.
  • various inventions can be formed by appropriately combining a plurality of constituent elements disclosed in the above-described embodiments. For example, some components may be deleted from all the components shown in the embodiment. Furthermore, constituent elements according to different embodiments may be appropriately combined.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

　複数のプロセッサからなる並列計算機に適用されるコンパイラであって、ソースプログラムを入力して前記プロセッサそれぞれのローカルコードを生成するコンパイラにおいて、入力した前記ソースプログラムを解析して、このソースプログラムに記述された手続きの中から前記プロセッサ間のデータ転送ポイントを抽出し、データコピーの呼び出し処理を生成する生成手段と、前記呼び出し処理を含むオブジェクトコードを生成する生成手段とを具備してなるコンパイラ。

Description

コンパイラ、オブジェクトコード生成方法、情報処理装置及び情報処理方法
　本発明の実施形態は、コンパイラ、オブジェクトコード生成方法、情報処理装置及び情報処理方法に関する。
　従来、マルチコア向けのプログラム実行モデルとしてマルチスレッド処理が存在している。かかるマルチスレッド処理では、実行単位となる複数のスレッドが並列に動作し、メインメモリ上のデータを遣り取りすることによって並列処理を遂行している。
　上記並列処理の実行形態の一例は、複数の実行単位を各実行ユニット（ＣＰＵコア）に割り当てるスケジューラを含むランタイム処理と、各実行ユニット上で動作するスレッドとの２つの要素で構成される。また、並列処理ではスレッド間の同期が重要であり、同期処理が適切でないとデッドロックやデータの整合性が崩れる等の問題が発生する。そこで、従来、スレッドの実行順序をスケジューリングし、このスケジュールに基づいて並列処理を行うことでスレッド間の同期を保持することが行われている。
　更にヘテロジニアスマルチコアの枠組みで、ＧＰＧＰＵ（General-purpose computing on graphics processing units; ＧＰＵによる汎目的計算、ＧＰＵの演算資源を画像処理以外の目的に応用する技術）をはじめとするアクセラレータなどの各デバイスのメモリ間やホストＣＰＵのメインメモリ間のデータコピーを暗黙的に行うランタイム環境が求められている。
　例えば、アクセラレーション計算環境におけるバッファ同期と並列ランタイムを重視し、ＣＰＵとＧＰＵカードなどのアクセラレータとで協調して大規模計算を実行する場合、ＣＰＵとＧＰＵの間でデータをやりとりするためにバッファを定義し、計算する側のメモリへデータを転送して並列計算を実行する。
　このとき、どういうタイミングでどちらの向きにデータを転送するのかを、プログラムコード上で表現するのは、煩雑でありコーディングでバグを混入する原因となる。とくに計算をＣＰＵ，ＧＰＵ１，ＧＰＵ２，…等のどこで実行するかを、プログラムチューニング過程で変更する場合はデータ転送のタイミングや向きに注意が必要となる。
　そこで、バッファを抽象化したバッファビューを定義し、バッファビューのデータ構造内にどこのメモリに最新データが存在するかという状態を保持することで、オンデマンドで必要に応じてデータのコピーを行う方法が提案されている。この方法を使うと、プログラムコード上でデータ転送を明示的に記述する必要がなく、必要に応じて正しくデータが転送されるため、簡潔なコードで信頼性の高いプログラムを書くことが可能である。
　しかし、オンデマンドでデータをコピーする方法では、並列計算処理（以降カーネルと呼ぶ）を呼び出すタイミングまで、データコピーの必要性が判明しないため、データコピーの遅延を甘受しなければならなかった。
　より効率のよいアクセラレーション計算プログラムを簡潔に実装することができる技術が、求められている。
特開平１０－２４０７０３号公報 特開２００８－１２３３１５号公報
　本発明の実施の形態は、より効率のよいアクセラレーション計算プログラムを簡潔に実装することができる技術を提供することを目的とする。
　実施形態によればコンパイラは、複数のプロセッサからなる並列計算機に適用されるコンパイラであって、ソースプログラムを入力して前記プロセッサそれぞれのローカルコードを生成するコンパイラにおいて、入力した前記ソースプログラムを解析して、このソースプログラムに記述された手続きの中から前記プロセッサ間のデータ転送ポイントを抽出し、データコピーの呼び出し処理を生成する生成手段と、前記呼び出し処理を含むオブジェクトコードを生成する生成手段とを具備する。
図１は実施形態のシステム全体の構成の一例を示す図である。 図２は同実施形態のシステム構成の一例を示す機能ブロック構成図である。 図３Ａは同実施形態でＣＰＵがカーネルを呼び出す順番の一例を示すための図である。 図３Ｂは同実施形態のデータフローの一例を説明するための図である。 図３Ｃは同実施形態のデータ処理シーケンスの一例を説明するための図である。 図３Ｄは同実施形態のデータとカーネルの種類の一例を示すための図である。 図４は一般的なコンパイラの動作原理の一例を説明する図である。 図５は実施形態のデータコピーポイントの計算とコピーコードの挿入の一例を示すフロー図である。 図６Ａは同実施形態でＣＰＵがカーネルを呼び出す順番の一例を示すための図である。 図６Ｂは同実施形態のデータフローの一例を説明するための図である。 図６Ｃは同実施形態のデータ処理シーケンスの一例を説明するための図である。 図６Ｄは同実施形態のバッファビューのデータ構造の一例を示すための図である。 図７は実施形態のシステム全体の構成の他の例を示す図である。 図８は同実施形態に用いられるシステム構成の一例を示す機能ブロック構成図である。
実施形態
　以下、一実施形態を説明する。
（第１の実施形態）
　本実施形態は情報処理装置として或いは情報処理方法として用いることができ、ソースプログラムを入力して並列計算機を構成するプロセッサそれぞれのローカルコードを生成するコンパイラに適用できるオブジェクトコード生成方法に係わり、このオブジェクトコード生成方法はプロセッサ構造に依存しないローカルコードを生成することを可能とする。
　第１の実施形態を図１乃至図８を参照して説明する。
　図１に実施形態のシステム全体の構成の一例を示す。例えば、ＧＰＵ等である計算デバイス１０（以下、ＧＰＵとも称する）はホストＣＰＵ１２により制御される。計算デバイス１０はマルチコアプロセッサからなり、多数のコアブロックに分割されている。図１の例では、計算デバイス１０は８つのコアブロック３４に分割される。計算デバイス１０はコアブロック３４毎に別のコンテキストを管理できる。コアブロックは１６個のコアからなる。コアブロックあるいはコアを並列に動作させることにより、高速なタスク並列処理が可能となる。
　コアブロック３４はブロックＩＤにより識別され、図１の例では、ブロックＩＤは０～７である。ブロック内の１６個のコアはローカルＩＤにより識別され、ローカルＩＤは０～１５である。ローカルＩＤが０のコアはブロックの代表コア３２と称される。
　ホストＣＰＵ１２もマルチコアプロセッサであってもよい。図１の例では、デュアルコアプロセッサとする。ホストＣＰＵ１２は３段階のキャッシュメモリ階層を持つ。メインメモリ１６と接続されるＬ１キャッシュ２２はホストＣＰＵ１２内に設けられ、Ｌ２キャッシュ２６ａ、２６ｂと接続される。Ｌ２キャッシュ２６ａ、２６ｂはそれぞれＣＰＵコア２４ａ、２４ｂに接続される。Ｌ１キャッシュ２２とＬ２キャッシュ２６ａ、２６ｂはハードウェアによる同期機構を持ち、同一アドレスへのアクセスの際に必要な同期処理が行われる。Ｌ２キャッシュ２６ａ、２６ｂはＬ１キャッシュ２２で参照されるアドレスのデータを保持し、キャッシュミスが生じた場合などにはハードウェアによる同期機構により、メインメモリ１６との間で必要な同期処理が行われる。
　計算デバイス１０によりアクセスできるデバイスメモリ１４が計算デバイス１０に接続され、ホストＣＰＵ１２にメインメモリ１６が接続される。メインメモリ１６とデバイスメモリ１４の２つのメモリが接続されているので、計算デバイス１０で処理を実行する前後で、デバイスメモリ１４とメインメモリ１６とでデータのコピー（同期化）を行う。このため、メインメモリ１６とデバイスメモリ１４とが互いに接続されている。なお、複数の処理を連続して実行する場合、１つの処理毎にコピーを実行する必要はない。
　図２にシステム機能構成例を示す。計算デバイス１０はＰＣＩｅ（ＰＣＩ　Ｅｘｐｒｅｓｓ）を経由してホストＣＰＵ１２と接続され、計算デバイス１０は専用のデバイスメモリ（ＤＲＡＭからなる）１４を持つ。計算に利用するデータを格納するバッファの実体はホストＣＰＵ１２のメインメモリ１６と、計算デバイス１０のデバイスメモリ１４にそれぞれ割り当てられ、ＢｕｆｆｅｒＶｉｅｗというデータ構造によって状態を管理される。
　このデータ構造は、図２に示すように４つの要素を含んでいる。ホストＣＰＵ１２とＧＰＵ１０で共有となる対象データをデータＡとすると、まずＳｉｚｅはこのデータＡのサイズ（バイト数）である。次に述べるＳｔａｔｅ（状態）の他にはＣｐｕ＿ｍｅｍとＧｐｕ＿ｍｅｍとがある。
　Ｃｐｕ＿ｍｅｍはメインメモリ１６内のデータＡの位置を表すポインタであり、Ｇｐｕ＿ｍｅｍはデバイスメモリ１４内のデータＡの位置を表すポインタである。
　さてＢｕｆｆｅｒＶｉｅｗの状態は、ＣＰＵのみ、ＧＰＵのみ、共有、未定義の４つの状態（計算デバイスが増えると状態は増える）で管理される。図３Ａは「ホストＣＰＵ１２でカーネル関数を呼び出す順序」を示す。図３Ａはプログラムコードに記載されたカーネル呼び出しであり、図の例ではカーネル関数ＫＥ，ＫＦ，ＫＩ，ＫＪがホストＣＰＵ１２で実行され、カーネル関数ＫＧ，ＫＨがＧＰＵ２０で実行される。図３Ｂは処理全体のデータフローの一例を示す。図３Ｃはデータ処理シーケンスの一例を示す。図３Ｄはデータとカーネルの種類の一例を示す。
　従来の技術では、オンデマンドでデータコピーを行う仕組みになっており、図３Ａから図３Ｄに示すようにホストＣＰＵ１２上でカーネルＫＥを実行するとＢｕｆｆｅｒＶｉｅｗ　Ｅの状態は「ＣＰＵのみ」となりカーネルＫＦについても同様である。ここで、ＧＰＵで実行するカーネルＫＨが呼び出されると、ＢｕｆｆｅｒＶｉｅｗ　Ｅ，Ｆの状態をチェックし、状態が「ＣＰＵのみ」であるために、データコピーを起動する。コピーが完了すると状態を「共有」に変更する。同様にＢｕｆｆｅｒＶｉｅｗ　Ｇ，Ｈは、カーネルＫＧ，ＫＨ終了時は、「ＧＰＵのみ」の状態であり、カーネルＫＩを呼び出したときに初めてＢｕｆｆｅｒＶｉｅｗ　Ｇのコピーが開始されるため、カーネルＫＩの実行開始が遅れてしまう。
　これを解決するためにＢｕｆｆｅｒＶｉｅｗ　Ｇのコピー開始をカーネルＫＧの終了直後に開始すればよいが、これではプログラミングが煩雑となり、ＢｕｆｆｅｒＶｉｅｗによる抽象化の利便性を損なってしまう。
　本実施形態に係わるオブジェクトコード生成方式を適用してなる一般的なコンパイラの概略構成は、コンパイラ、最適化変換部及びコード生成部を有してなる。コンパイラは、ソースプログラムを読み込み、構文解析して中間コードに変換してメモリの中に格納する。具体的には、ソースプログラムを構文解析し中間コードを生成し、その後最適化、コード生成、オブジェクトコードの出力となる。この最適化の中では、制御フロー解析、データ依存解析、様々な最適化（中間コード変換）という流れである。後述のＤｅｆ－Ｕｓｅチェインの解析はデータ依存解析であり、データ転送コードの挿入はさまざまな最適化とコード生成部で実現される機能である。
　ここで、図４を参照して一般的な並列コンパイラの動作手順の概略を示す。
　まず、コンパイルの最初にターゲットプロセッサの構成Ｂ２１を指定する。なお、コンパイラ指示子等と呼ばれるものを援用することにより指定してもよい。そして、コンパイラは、ステップＳ２２においてソースプログラムＢ２５を読み込み、構文解析してソースプログラムＢ２５を内部表現である中間形式Ｂ２６に変換する。
　次に、コンパイラは、ステップＳ２３において中間形式（内部表現）Ｂ２６に対して様々な最適化変換を行い、変換された中間形式Ｂ２７を生成する。
　次に、コンパイラは、ステップＳ２４にて変換された中間形式Ｂ２７をスキャンして、ＰＥそれぞれのオブジェクトコードＢ２８を生成する。コンパイラの動作例としてはＣ言語系列のプログラムから、機械語コードを生成することがある。
　本実施形態では、図５に示すように、プログラムコンパイル時にデータフローを解析し、必要な場合のみデータコピー開始のためのコードを挿入する。具体的には、ＢｕｆｆｅｒＶｉｅｗのＤｅｆ－Ｕｓｅチェインを解析し、ＤｅｆするカーネルとＵｓｅするカーネルの実行デバイスが異なる場合のみ、Ｄｅｆするカーネルの直後でデータコピーをキックするコードを挿入する。これにより、プログラムを簡潔に保ったままデータの先読みが可能となり、図３Ｃに示すタイムチャートの通り、カーネルＫＩの実行を早期に開始することが可能となり（図３ＣのＫＧからＫＩ，ＫＨからＫＪへの破線を参照。従来ではＫＨが終了してからＫＩへ移行する）、全体の実行時間を短縮できる。なお、図３Ｄは、図３Ｂのデータフローに関するデータとカーネルの属性を列挙したものである。
　Ｄｅｆ－Ｕｓｅチェインは、ｄｕ－連鎖（ｄｅｆｉｎｉｔｉｏｎ　－　ｕｓｅ　ｃｈａｉｎ）と呼ばれてきたものである。定義－使用連鎖（ｄｕ－連鎖）の作成は、生きている変数の解析と本質的に同じ計算になる。例えば文ｓにおいて、変数が右辺値を要求することがあれば、その変数はｓで使用される。たとえば、文ａ　：　＝　ｂ　＋　ｃ　と文ａ　［　ｂ　］：＝　ｃ　があれば、ｂとｃはそれぞれの文で使用される（ａは使用されない）。ｄｕ－連鎖の問題は、ある点ｐについて、変数ｘを使用する文ｓの集合を求めることである。具体的なステップは次のようになる。
ステップＳ７１：　プログラムを基本ブロックに分割する。
ステップＳ７２：　制御フローのグラフを作成する。
ステップＳ７３：　ＢｕｆｆｅｒＶｉｅｗに対してデータフローを解析しＤｅｆ－Ｕｓｅチェインを作成する。
　すべてのＢｕｆｆｅｒＶｉｅｗのＤｅｆ－Ｕｓｅチェインに対して以下の処理を実行する。
ステップＳ７４Ａ：　すべてのＢｕｆｆｅｒＶｉｅｗのＤｅｆ－Ｕｓｅチェインの処理が実行されたか判定し、実行されたと判定されればステップＳ７４Ｃまでの処理ループから抜け全体の処理を終了する。
ステップＳ７４Ｂ：　ＢｕｆｆｅｒＶｉｅｗをＤｅｆするカーネルの実行デバイスとＢｕｆｆｅｒＶｉｅｗをＵｓｅするカーネルの実行デバイスとが異なるか判定し、この判定がＹｅｓならば次のステップＳ７４Ｃに進み、ＮｏならばステップＳ７４Ａに戻る。
ステップＳ７４Ｃ：　Ｄｅｆするカーネルの実行直後にデータコピーを起動するコードを挿入する。このデータコピーの呼び出し処理を生成するためのコードは、例えば関数により実現される。
　ここで基本ブロックとは連続した文の列からなり、制御は先頭の文に与えられ、そのあと、途中で停止したり、途中から分岐したりしないで、最後の文から制御が離れるものをいう。例えば所謂三番地文の列は基本ブロックを形成する。
　尚さらに、図６Ｄに示すようにＢｕｆｆｅｒＶｉｅｗにデータの分割方法（ＢｌｏｃｋＳｉｚｅ）をあらかじめ定義しておくことをバッファＧとＩに適用し、カーネルＫＩが並列度の低いＣＰＵで実行されるということを考慮してカーネルＫＧ，ＫＩを分割実行することによって（図６Ａ、図６ＢのカーネルＫＧとＫＩを参照）全体の実行時間を短くすることが可能である（図６ＣのカーネルＫＧからＫＩへの３本の破線を参照）。ＢｌｏｃｋＳｉｚｅ（３０００バイト）はＳｉｚｅ（９０００バイト）を３分割した値となっている。図６ＡはＣＰＵがカーネルを呼び出す順番の一例を示す。図６Ｂはデータフローの一例を示す。図６Ｃはバッファビューのデータ構造の一例を示す。図６Ｄはデータ処理シーケンスの一例を示す。
（第２の実施形態）
　本発明による第２の実施形態を図７乃至図８を参照して説明する。実施形態１と共通する部分は説明を省略する。
　図７はシステム構成の他の例を示す図である。ここでは、デバイスメモリ１４を単独で設けずに、計算デバイス１０とホストＣＰＵ１２がメインメモリ１６を共有し、メインメモリ１６内に図１のデバイスメモリ１４と等価なデバイスメモリ領域１４Ｂが設けられる。この場合は、デバイスメモリとメインメモリとでデータのコピーを行う必要がない。
　図８の機能ブロックに示すように本実施形態は、共有キャッシュ１６Ｂを介在として、メモリ領域１４Ｂが設けられている。
　結果としてＣＰＵ，ＧＰＵを統合し共有メモリをもつＳｏＣ（Ｓｙｓｔｅｍ　ｏｎ　Ｃｈｉｐ）に対しては、実施形態１におけるデータのコピーは、キャッシュへのプリフェッチへと置き換えることで、ＣＰＵ／ＧＰＵ／その他アクセラレータがメモリを共有する場合においても、簡潔なプログラム記述における性能向上のための有効な手段となる。なおｍｅｍは、共有キャッシュ１６Ｂ内のデータＡの位置を表すポインタである。
　以上に説明したように複雑で手間のかかるＧＰＵプログラミングを簡潔にした環境においても、データ転送の遅延を自動的に隠ぺいすることにより高効率なプログラムを作成することが可能である。
（実施形態のまとめ）
　計算対象のデータバッファを抽象化することにより、ＧＰＧＰＵをはじめとするアクセラレータなどの各デバイスのメモリ間やホストＣＰＵのメインメモリ間のデータコピーを暗黙的に行うランタイム環境において、以下のことを実施する。
（１）オンデマンドでデータコピーを発行するのではなく、できるだけ早い時点でデータコピーを発行することにより、データ移動の遅延を少なくし性能を向上させる。
（２）早い時点でデータをコピーするために、プログラムコンパイル時にデータ転送ポイントを求めてデータコピーの呼び出し処理を生成する。
（３）また、マルチコアＣＰＵなどの比較的並列度が低いデバイスで計算する場合は、入力データバッファを細分化してストリーム的にデータを流してマルチコアＣＰＵでの計算開始タイミングを早くすることにより、システム性能を向上させる。
　本実施形態によれば、プログラマはデータの転送処理を記述することなく、適切なタイミングでデータのコピーを起動するプログラムを作成できるため、効率のよいアクセラレーション計算プログラムを簡潔に実装することが可能となる。
　なお、この発明は上記実施形態に限定されるものではなく、この外その要旨を逸脱しない範囲で種々変形して実施することができる。
　また、上記した実施の形態に開示されている複数の構成要素を適宜に組み合わせることにより、種々の発明を形成することができる。例えば、実施の形態に示される全構成要素から幾つかの構成要素を削除しても良いものである。さらに、異なる実施の形態に係わる構成要素を適宜組み合わせても良いものである。

Claims (6)

  1. 　複数のプロセッサからなる並列計算機に適用されるコンパイラであって、ソースプログラムを入力して前記プロセッサそれぞれのローカルコードを生成するコンパイラにおいて、
    　入力した前記ソースプログラムを解析して、このソースプログラムに記述された手続きの中から前記プロセッサ間のデータ転送ポイントを抽出し、データコピーの呼び出し処理を生成する生成手段と、
    　前記呼び出し処理を含むオブジェクトコードを生成する生成手段と、
    　を具備するコンパイラ。
  2. 　前記データ転送ポイントを前記プロセッサ単位で細分化する請求項１に記載のコンパイラ。
  3. 　前記データコピーの呼び出し処理は前記プロセッサ間の共有キャッシュへのプリフェッチに置き換えて生成される請求項１に記載のコンパイラ。
  4. 　前記プロセッサとして、請求項１に記載のコンパイラにより生成されたオブジェクトコードを実行するＣＰＵ及びアクセラレータを具備する情報処理装置。
  5. 　複数のプロセッサからなる並列計算機に適用されるコンパイラであり、ソースプログラムを入力して前記プロセッサそれぞれのローカルコードを生成するコンパイラにおけるオブジェクトコード生成方法であって、
    　入力した前記ソースプログラムを解析して、このソースプログラムに記述された手続きの中から前記プロセッサ間のデータ転送ポイントを抽出し、データコピーの呼び出し処理を生成する生成工程と、
    　前記呼び出し処理を含むオブジェクトコードを生成する生成工程と、
    　を具備するオブジェクトコード生成方法。
  6. 　請求項５に記載のオブジェクトコード生成方法により生成されたオブジェクトコードを実行する情報処理方法。
PCT/JP2013/058157 2013-02-04 2013-03-21 コンパイラ、オブジェクトコード生成方法、情報処理装置及び情報処理方法 WO2014119003A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US14/015,670 US20140223419A1 (en) 2013-02-04 2013-08-30 Compiler, object code generation method, information processing apparatus, and information processing method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2013-019259 2013-02-04
JP2013019259A JP2014149765A (ja) 2013-02-04 2013-02-04 コンパイラ、オブジェクトコード生成方法、情報処理装置及び情報処理方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/015,670 Continuation US20140223419A1 (en) 2013-02-04 2013-08-30 Compiler, object code generation method, information processing apparatus, and information processing method

Publications (1)

Publication Number Publication Date
WO2014119003A1 true WO2014119003A1 (ja) 2014-08-07

Family

ID=51261743

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/058157 WO2014119003A1 (ja) 2013-02-04 2013-03-21 コンパイラ、オブジェクトコード生成方法、情報処理装置及び情報処理方法

Country Status (2)

Country Link
JP (1) JP2014149765A (ja)
WO (1) WO2014119003A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012533124A (ja) * 2009-07-10 2012-12-20 アップル インコーポレイテッド ブロックベースの非透過的キャッシュ
JP2013500543A (ja) * 2009-07-27 2013-01-07 アドバンスト・マイクロ・ディバイシズ・インコーポレイテッド データ並列スレッドを有する処理論理の複数のプロセッサにわたるマッピング

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012533124A (ja) * 2009-07-10 2012-12-20 アップル インコーポレイテッド ブロックベースの非透過的キャッシュ
JP2013500543A (ja) * 2009-07-27 2013-01-07 アドバンスト・マイクロ・ディバイシズ・インコーポレイテッド データ並列スレッドを有する処理論理の複数のプロセッサにわたるマッピング

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
DAI MICHIURA ET AL.: "Automatic generation of data transfer code for GPGPU compiler", IPSJ SIG NOTES - VOL.2011HPC130, vol. 2011, no. 17, 2011, pages 1 - 9 *
HIROAKI UCHIYAMA ET AL.: "An Automatic Device Memory Allocation Method for OpenMPC", IEICE TECHNICAL REPORT - VOL. CPSY2012-17, vol. 112, no. 173, 26 July 2012 (2012-07-26), pages 49 - 54 *
NAOYA MARUYAMA ET AL.: "Tokushu GPU to sono Oyo 3. OpenACC Programming", THE JOURNAL OF THE INSTITUTE OF IMAGE INFORMATION AND TELEVISION ENGINEERS, vol. 66, no. 10, 1 October 2012 (2012-10-01), pages 817 - 822 *
TOSHIYA KOMODA ET AL.: "CPU/GPU-kan Data Tsushin Muke Sakiyomi Kiko no Kento", IPSJ SIG NOTES, vol. ARC-201, no. 25, 2012, pages 1 - 8 *

Also Published As

Publication number Publication date
JP2014149765A (ja) 2014-08-21

Similar Documents

Publication Publication Date Title
EP3262503B1 (en) Hardware instruction generation unit for specialized processors
JP6525286B2 (ja) プロセッサコア及びプロセッサシステム
US8250549B2 (en) Variable coherency support when mapping a computer program to a data processing apparatus
JP6319880B2 (ja) 並列性の抽出方法及びプログラムの作成方法
Newburn et al. Offload compiler runtime for the Intel® Xeon Phi coprocessor
US9996394B2 (en) Scheduling accelerator tasks on accelerators using graphs
US11900113B2 (en) Data flow processing method and related device
KR20180021812A (ko) 연속하는 블록을 병렬 실행하는 블록 기반의 아키텍쳐
JP2009259241A (ja) 汎用プロセッサによるリターゲティングされたグラフィックプロセッサ加速コードの実行
US9645802B2 (en) Technique for grouping instructions into independent strands
US10318261B2 (en) Execution of complex recursive algorithms
EP3895022B1 (en) Improving emulation and tracing performance using compiler-generated emulation optimization metadata
JP2009524866A (ja) プログラムの並列実行のためのシステム及び方法
US10198544B2 (en) Method for improving OpenCL hardware execution efficiency
WO2023107789A1 (en) Deterministic replay of a multi-threaded trace on a multi-threaded processor
US20140223419A1 (en) Compiler, object code generation method, information processing apparatus, and information processing method
WO2014119003A1 (ja) コンパイラ、オブジェクトコード生成方法、情報処理装置及び情報処理方法
JP5238876B2 (ja) 情報処理装置及び情報処理方法
WO2023123453A1 (zh) 运算加速的处理方法、运算加速器的使用方法及运算加速器
Larsen Multi-GPU Futhark Using Parallel Streams
Kaushik Accelerating Mixed-Abstraction SystemC Models on Multi-Core CPUs and GPUs

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13873214

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13873214

Country of ref document: EP

Kind code of ref document: A1