OpenHMPP

OpenHMPP (HMPP for Hybrid Multicore Parallel Programming) - programming standard for heterogeneous computing. Based on a set of compiler directives, 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 (HWA).

OpenHMPP (HMPP for Hybrid Multicore Parallel Programming) - programming standard for heterogeneous computing. Based on a set of compiler directives, 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 (HWA). Reserved HMPP keywords are in green ; Elements of grammar which can be declined in HMPP keywords are in red ; User's variables remain in black. #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: . 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: 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). 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[ ].advancedload=true : indicates that the specified parameters are preloaded. Only in or inout parameters can be preloaded. 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[ ].const=true : indicates that the argument is to be uploaded only once. #pragma hmpp grp_label > codelet_label codelet [ , version = major.minor[.micro]?]? [ , args[ arg_items ].io= out | inout * [ , 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 : /* declaration of the codelet */ #pragma hmpp simple1 codelet, args[outv].io=inout, target=CUDA static void matvec(int sn, int sm, float inv[sm], float inm[sn][sm], float *outv){ int i, j; for (i = 0 ; i 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 ” ]? #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. int main(int argc, char **argv) { #pragma hmpp sgemm allocate, args[vin1;vin2;vout].size={size,size} #pragma hmpp sgemm advancedload, args[vin1;vin2;vout], args[m,n,k,alpha,beta] for ( j = 0 ; j #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]+ #pragma hmpp grp_label > resident [ , args[:: var_name ].io= out | inout * [ , 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. #pragma hmpp [ MyGroup >] [ label ] region [ , args[ arg_items ].io= out | inout * [ , 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 }

Text derived from https://en.wikipedia.org/w/index.php?oldid=1312009512 under CC BY-SA 4.0; modifications have been made.