HMPP Open Standard
Encyclopedia
HMPP for Hybrid Multicore Parallel Programming.
Based on a set of directives, OpenHMPP Standard is a programming model designed to handle hardware accelerators without the complexity associated with GPU programming
. This approach based on directives has been implemented because they enable a loose relationship between an application code and the use of a hardware accelerator.
This article deals with HMPP directives which constitute OpenHMPP, but does not address the execution of the directives linked to the directives implementation.
The model is based on works initialized by CAPS (Compiler and Architecture for Embedded and Superscalar Processors), a common project from INRIA, CNRS, the University of Rennes 1
and the INSA of Rennes.
.
These properties ensure that a codelet RPC
can be remotely executed by a HWA. This RPC and its associated data transfers can be asynchronous.
The table below introduces the OpenHMPP directives. OpenHMPP directives address different needs: some of them are dedicated to declarations and others are dedicated to the management of the execution.
There are two kinds of labels:
s will be used to describe the syntax of the HMPP directives.
The color convention below is used for the description of syntax directives:
The general syntax of OpenHMPP directives is:
#pragma hmpp <grp_label> [codelet_label]? directive_type [,directive_parameters]* [&]
!$hmpp <grp_label> [codelet_label]? directive_type [,directive_parameters]* [&]
Where:
The parameters associated to a directive may be of different types.
Below are the directive parameters defined in OpenHMPP:
For the
The syntax of the directive is:
#pragma hmpp <grp_label> codelet_label codelet
[, version = major.minor[.micro]?]?
[, args[arg_items].io=out*
[, args[arg_items].size={dimsize[,dimsize]*}]*
[, args[arg_items].const=true]*
[, cond = "expr"]
[, target=target_name[:target_name]*]
More than one codelet directive can be added to a function in order to specify different uses or different execution contexts. However, there can be only one codelet directive for a given call site label.
The
The syntax of the directive is:
#pragma hmpp <grp_label> codelet_label callsite
[, asynchronous]?
[, args[arg_items].size={dimsize[,dimsize]*}]*
[, args[arg_items].advancedload=false*
[, args[arg_items].addr="expr"]*
[, args[arg_items].noupdate=true]*
An example is shown here :
In some cases, a specific management of the data throughout the application is required (CPU/GPU data movements optimization, shared variables...).
The
The syntax of the directive is:
#pragma hmpp <grp_label> group
[, version =.[.]?]?
[, target = target_name[:target_name]*]]?
[, cond = “expr”]?
To limit the communication overhead, data transfers can be overlapped with successive executions of the same codelet by using the asynchronous property of the HWA.
The
#pragma hmpp <grp_label> allocate [,args[arg_items].size={dimsize[,dimsize]*}]*
The
#pragma hmpp <grp_label> release
The
#pragma hmpp <grp_label> [codelet_label]? advancedload
,args[arg_items]
[,args[arg_items].size={dimsize[,dimsize]*}]*
[,args[arg_items].addr="expr"]*
[,args[arg_items].section={[subscript_triplet,]+}]*
[,asynchronous]
The
#pragma hmpp <grp_label> [codelet_label]? delegatedstore
,args[arg_items]
[,args[arg_items].addr="expr"]*
[,args[arg_items].section={[subscript_triplet,]+}]*
The
For the synchronize directive, the codelet label is always mandatory and the group label is required if the codelet belongs to a group.
#pragma hmpp <grp_label> codelet_label synchronize
In the following example, the device initialization, memory allocation and upload of the input data are done only once outside the loop and not in each iteration of the loop.
The
The types and dimensions of all mapped arguments must be identical.
The
#pragma hmpp <grp_label> map, args[arg_items]
This directive is quite similar as the
#pragma hmpp <grp_label> mapbyname [,variableName]+
This directive applies to the declaration statement just following it in the source code.
The syntax of this directive is:
#pragma hmpp <grp_label> resident
[, args[::var_name].io=out*
[, args[::var_name].size={dimsize[,dimsize]*}]*
[, args[::var_name].addr="expr"]*
[, args[::var_name].const=true]*
The notation
In C language:
#pragma hmpp [<MyGroup>] [label] region
[, args[arg_items].io=out*
[, cond = "expr"]<
[, args[arg_items].const=true]*
[, target=target_name[:target_name]*]
[, args[arg_items].size={dimsize[,dimsize]*}]*
[, args[arg_items].advancedload=false*
[, args[arg_items].addr="expr"]*
[, args[arg_items].noupdate=true]*
[, asynchronous]?
[, private=[arg_items]]*
{
C BLOCK STATEMENTS
}
The OpenHMPP directive-based programming model is implemented in:
OpenHMPP is used by HPC
actors in Oil & Gas, Energy, Manufacturing, Finance, Education & Research.
Based on a set of directives, OpenHMPP Standard is a programming model designed to handle hardware accelerators without the complexity associated with GPU programming
GPGPU
General-purpose computing on graphics processing units is the technique of using a GPU, which typically handles computation only for computer graphics, to perform computation in applications traditionally handled by the CPU...
. This approach based on directives has been implemented because they enable a loose relationship between an application code and the use of a hardware accelerator.
This article deals with HMPP directives which constitute OpenHMPP, but does not address the execution of the directives linked to the directives implementation.
Introduction
The OpenHMPP directive-based programming model offers a syntax to offload computations on hardware accelerators and to optimize data movement to/from the hardware memory.The model is based on works initialized by CAPS (Compiler and Architecture for Embedded and Superscalar Processors), a common project from INRIA, CNRS, the University of Rennes 1
University of Rennes 1
The University of Rennes 1 is one of the two main universities in the city of Rennes, France. It is under the Academy of Rennes. It specializes in science, technology, law, economy, management and philosophy. The University of Rennes 1 has been in existence since 1969, but its heritage stems back...
and the INSA of Rennes.
OpenHMPP concept
OpenHMPP is based on the concept of codelets, functions that can be remotely executed on HWAsHardware
Hardware is a general term for equipment such as keys, locks, hinges, latches, handles, wire, chains, plumbing supplies, tools, utensils, cutlery and machine parts. Household hardware is typically sold in hardware stores....
.
The OpenHMPP codelet concept
A codelet has the following properties:- It is a pure functionPure functionIn computer programming, a function may be described as pure if both these statements about the function hold:# The function always evaluates the same result value given the same argument value...
.- It does not contain staticStatic variableIn computer programming, a static variable is a variable that has been allocated statically — whose lifetime extends across the entire run of the program...
or volatileVolatile variableIn computer programming, particularly in the C, C++, C#, and Java programming languages, a variable or object declared with the volatile keyword usually has special properties related to optimization and/or threading...
variable declarations nor refer to any global variables except if these have been declared by a HMPP directive “resident” - It does not contain any function calls with an invisible body (that cannot be inlined). This includes the use of libraries and system functions such as malloc, printf, ...
- Every function call must refer to a static pure function (no function pointers).
- It does not contain static
- It does not return any value (void function in CC (programming language)C is a general-purpose computer programming language developed between 1969 and 1973 by Dennis Ritchie at the Bell Telephone Laboratories for use with the Unix operating system....
or a subroutine in FortranFortranFortran is a general-purpose, procedural, imperative programming language that is especially suited to numeric computation and scientific computing...
). - The number of arguments should be fixed (i.e. it can not be a variadic functionVariadic functionIn computer programming, a variadic function is a function of indefinite arity, i.e., one which accepts a variable number of arguments. Support for variadic functions differs widely among programming languages....
as in stdarg.hStdarg.hstdarg.h is a header in the C standard library of the C programming language that allows functions to accept an indefinite number of arguments. It provides facilities for stepping through a list of function arguments of unknown number and type...
in C). - It is not recursive.
- Its parameters are assumed to be non-aliased (see Aliasing (computing)Aliasing (computing)In computing, aliasing describes a situation in which a data location in memory can be accessed through different symbolic names in the program. Thus, modifying the data through one name implicitly modifies the values associated to all aliased names, which may not be expected by the programmer...
and Pointer aliasing). - It does not contain callsite directives (i.e. RPC to another codelet) or other HMPP directives.
These properties ensure that a codelet RPC
Remote procedure call
In computer science, a remote procedure call is an inter-process communication that allows a computer program to cause a subroutine or procedure to execute in another address space without the programmer explicitly coding the details for this remote interaction...
can be remotely executed by a HWA. This RPC and its associated data transfers can be asynchronous.
Codelet RPCs
HMPP provides synchronous and asynchronous RPC. Implementation of asynchronous operation is hardware dependent.HMPP Memory Model
HMPP considers two address spaces: the host processor one and the HWA memory.Directives concept
The OpenHMPP directives may be seen as “meta-information” added in the application source code. They are safe meta-information i.e. they do not change the original code behavior. They address the remote execution (RPC) of a function as well as the transfers of data to/from the HWA memory.The table below introduces the OpenHMPP directives. OpenHMPP directives address different needs: some of them are dedicated to declarations and others are dedicated to the management of the execution.
Control flow instructions | Directives for data management | |
Declarations | codelet group |
resident map mapbyname |
Operational Directives | callsite synchronize region |
allocate release advancedload delegatedstore |
Concept of set of directives
One of the fundamental points of the HMPP approach is the concept of directives and their associated labels which makes it possible to expose a coherent structure on a whole set of directives disseminated in an application.There are two kinds of labels:
- One associated to a codelet. In general, the directives carrying this kind of labels are limited to the management of only one codelet (called stand-alone codelet in the remainder of the document to distinguish it from the group of codelets).
- One associated to a group of codelets. These labels are noted as follow: “
“, where “LabelOfGroup” is a name specified by the user. In general, the directives which have a label of this type relate to the whole group. The concept of group is reserved to a class of problems which requires a specific management of the data throughout the application to obtain performance.
OpenHMPP Directives Syntax
In order to simplify the notations, regular expressionRegular expression
In computing, a regular expression provides a concise and flexible means for "matching" strings of text, such as particular characters, words, or patterns of characters. Abbreviations for "regular expression" include "regex" and "regexp"...
s will be used to describe the syntax of the HMPP directives.
The color convention below is used for the description of syntax directives:
- Reserved HMPP keywords are in blue;
- Elements of grammar which can be declined in HMPP keywords are in red;
- User’s variables remain in black.
General syntax
The general syntax of OpenHMPP directives is:
- For C language:
#pragma hmpp <grp_label> [codelet_label]? directive_type [,directive_parameters]* [&]
- For FORTRAN language:
!$hmpp <grp_label> [codelet_label]? directive_type [,directive_parameters]* [&]
Where:
: is a unique identifier naming a group of codelets. In cases where no groups are defined in the application, this label can simply miss. Legal label name must follow this grammar: [a-z,A-Z,_][a-z,A-Z,0-9,_]*. Note that the “< >” characters belong to the syntax and are mandatory for this kind of label.codelet_label
: is a unique identifier naming a codelet. Legal label name must follow this grammar: [a-z,A-Z,_][a-z,A-Z,0-9,_]*directive
: is the name of the directive;directive_parameters
: designates some parameters associated to the directive. These parameters may be of different kinds and specify either some arguments given to the directive either a mode of execution (asynchronous versus synchronous for example);[&]
: is a character used to continue the directive on the next line (same for C and FORTRAN).
Directive parameters
The parameters associated to a directive may be of different types.
Below are the directive parameters defined in OpenHMPP:
-
version = major.minor[.micro]
: specifies the version of the HMPP directives to be considered by the preprocessor. -
args[arg_items].size={dimsize[,dimsize]*}
: specifies the size of a non scalar parameter (an array). -
args[arg_items].io=[in|out|inout]
: indicates that the specified function arguments are either input, output or both. By default, unqualified arguments are inputs. -
cond = "expr"
: specifies an execution condition as a boolean C or Fortran expression that needs to be true in order to start the execution of the group or codelets. -
target=target_name[:target_name]*
: specifies which targets to try to use in the given order. -
asynchronous
: specifies that the codelet execution is not blocking (default is synchronous). -
args[
: indicates that the specified parameters are preloaded. Only in or inout parameters can be preloaded.].advancedload=true -
args[arg_items].noupdate=true
: this property specifies that the data is already available on the HWA and so that no transfer is needed. When this property is set, no transfer is done on the considered argument -
args[
:].addr=" "
is an expression that gives the address of the data to upload. -
args[
: indicates that the argument is to be uploaded only once.].const=true
Directives for declaring and executing a codelet
Acodelet
directive declares a computation to be remotely executed on a hardware accelerator.For the
codelet
directive:
- The codelet label is mandatory and must be unique in the application
- The group label is not required if no group is defined.
- The codelet directive is inserted just before the function declaration.
The syntax of the directive is:
#pragma hmpp <grp_label> codelet_label codelet
[, version = major.minor[.micro]?]?
[, args[arg_items].io=out*
[, args[arg_items].size={dimsize[,dimsize]*}]*
[, args[arg_items].const=true]*
[, cond = "expr"]
[, target=target_name[:target_name]*]
More than one codelet directive can be added to a function in order to specify different uses or different execution contexts. However, there can be only one codelet directive for a given call site label.
The
callsite
directive specifies how the use a codelet at a given point in the program.The syntax of the directive is:
#pragma hmpp <grp_label> codelet_label callsite
[, asynchronous]?
[, args[arg_items].size={dimsize[,dimsize]*}]*
[, args[arg_items].advancedload=false*
[, args[arg_items].addr="expr"]*
[, args[arg_items].noupdate=true]*
An example is shown here :
In some cases, a specific management of the data throughout the application is required (CPU/GPU data movements optimization, shared variables...).
The
group
directive allows the declaration of a group of codelets. The parameters defined in this directive are applied to all codelets belonging to the group.The syntax of the directive is:
#pragma hmpp <grp_label> group
[, version =
[, target = target_name[:target_name]*]]?
[, cond = “expr”]?
Data transfers directives to optimize communication overhead
When using a HWA, the main bottleneck is often the data transfers between the HWA and the main processor.To limit the communication overhead, data transfers can be overlapped with successive executions of the same codelet by using the asynchronous property of the HWA.
- allocate directive
The
allocate
directive locks the HWA and allocates the needed amount of memory.#pragma hmpp <grp_label> allocate [,args[arg_items].size={dimsize[,dimsize]*}]*
- release directive
The
release
directive specifies when to release the HWA for a group or a stand-alone codelet.#pragma hmpp <grp_label> release
- advancedload directive
The
advancedload
directive prefetches data before the remote execution of the codelet.#pragma hmpp <grp_label> [codelet_label]? advancedload
,args[arg_items]
[,args[arg_items].size={dimsize[,dimsize]*}]*
[,args[arg_items].addr="expr"]*
[,args[arg_items].section={[subscript_triplet,]+}]*
[,asynchronous]
- delegatedstore directive
The
delegatedstore
directive is a synchronization barrier to wait for an asynchronous codelet execution to complete and to then download the results.#pragma hmpp <grp_label> [codelet_label]? delegatedstore
,args[arg_items]
[,args[arg_items].addr="expr"]*
[,args[arg_items].section={[subscript_triplet,]+}]*
- Asynchronous Computations
The
synchronize
directive specifies to wait until the completion of an asynchronous callsite execution.For the synchronize directive, the codelet label is always mandatory and the group label is required if the codelet belongs to a group.
#pragma hmpp <grp_label> codelet_label synchronize
- Example
In the following example, the device initialization, memory allocation and upload of the input data are done only once outside the loop and not in each iteration of the loop.
The
synchronize
directive allows to wait for the asynchronous execution of the codelet to complete before launching another iteration. Finally the delegatedstore
directive outside the loop uploads the sgemm result.Sharing data between codelets
Those directives map together all the arguments sharing the given name for all the group.The types and dimensions of all mapped arguments must be identical.
The
map
directive maps several arguments on the device.#pragma hmpp <grp_label> map, args[arg_items]
This directive is quite similar as the
map
directive except that the arguments to be mapped are directly specified by their name. The mapbyname
directive is equivalent to multiple map
directives.#pragma hmpp <grp_label> mapbyname [,variableName]+
Global variable
Theresident
directive declares some variables as global within a group. Those variables can then be directly accessed from any codelet belonging to the group.This directive applies to the declaration statement just following it in the source code.
The syntax of this directive is:
#pragma hmpp <grp_label> resident
[, args[::var_name].io=out*
[, args[::var_name].size={dimsize[,dimsize]*}]*
[, args[::var_name].addr="expr"]*
[, args[::var_name].const=true]*
The notation
::var_name
with the prefix ::
, indicates an application’s variable declared as resident.Acceleration of regions
A region is a merge of the codelet/callsite directives. The goal is to avoid code restructuration to build the codelet. Therefore, all the attributes available forcodelet
or callsite
directives can be used on regions
directives.In C language:
#pragma hmpp [<MyGroup>] [label] region
[, args[arg_items].io=out*
[, cond = "expr"]<
[, args[arg_items].const=true]*
[, target=target_name[:target_name]*]
[, args[arg_items].size={dimsize[,dimsize]*}]*
[, args[arg_items].advancedload=false*
[, args[arg_items].addr="expr"]*
[, args[arg_items].noupdate=true]*
[, asynchronous]?
[, private=[arg_items]]*
{
C BLOCK STATEMENTS
}
Implementations
The OpenHMPP Open Standard is based on HMPP Version 2.3 (May 2009, CAPS entreprise).The OpenHMPP directive-based programming model is implemented in:
- HMPP Workbench, the CAPS Entreprise compiler for hybrid computing
- PathScale ENZO Compiler Suite (support the NVIDIA GPUs)
OpenHMPP is used by HPC
High-performance computing
High-performance computing uses supercomputers and computer clusters to solve advanced computation problems. Today, computer systems approaching the teraflops-region are counted as HPC-computers.-Overview:...
actors in Oil & Gas, Energy, Manufacturing, Finance, Education & Research.