【并行计算-CUDA开发】OpenACC与OpenHMPP

在西雅图超级计算大会（SC11）上发布了新的基于指令的加速器并行编程标准，既OpenACC。这个开发标准的目的是让更多的编程人员可以用到GPU计算，同时计算结果可以跨加速器使用，甚至能用在多核CPU上。
出于显而易见的原因，NVIDIA在大力推广和支持OpenACC。但事实上PGI和Cray才是最早推动这项技术商业化的公司。PGI已经推出了一组非常类似的加速器指令，目前也成为了OpenACC标准的基础部分之一。Cray公司正在开发自己的OpenACC编译器，并且他的XK6客户如橡树岭国家实验室和瑞士国家超级计算机中心，预计将成为该技术的第一批超级计算机用户。
简而言之，OpenACC指令与OpenMP指令工作方式很类似，但前者特别适用于高度数据并行代码。它们可插入标准的C，C + +和Fortran程序直接指导编译器进行某些代码段的并行。编译器会特别注意数据在CPU和GPU（或其他）之间来回转移的逻辑关系，并将计算映射到适当的处理器上。
这样，开发人员就可以在现存的或者新的代码上做相对小的改动以标示出加速并行区域。由于指令设计适用于一个通用并行处理器，这样相同的代码可以运行在多核CPU、GPU或任何编译器支持的其他类型的并行硬件上。这种硬件的独立性对于HPC的用户来说特别重要，因为他们不愿意接受那种受供应商限制的，非便携式编程环境。
站在NVIDIA的角度，目标就是将GPU计算带入后CUDA时代。今天，CUDA
C和CUDA Fortran广泛用于GPU编程。但是这个底层技术属于NVIDIA，对于GPU计算提供了一个相对低阶的软件模型，因此想较于对一般编程人员或者研究人员，CUDA的使用对于计算科学类型而言受限制程度越来越明显。 
受NVIDIA、AMD等支持的OpenCL同样也提供了GPU和其他加速器的并行编程框架。与CUDA不一样的是，OpenCL是个真正开放的标准。 但与CUDA相似的是，OpenCL相对底层，需要对目标处理器的内部结构有一定了解。因此与CUDA一样，使用OpenCL对于计算机科学家来说有很大的局限性。  
NVIDIA公司估计这个星球上有超过10万的CUDA程序员和比较多的的OpenCL开发人员，但他们也意识到如果能够使GPU编程更加开放且开发界面更加友好，就会有一个更大的潜在观众。从本质上讲，他们认为OpenACC将能够被数以百万计的科学家和研究人员使用，这些人不需要关心和涉足处理器架构，也不需要关心芯片与芯片之间通信。
NVIDIA的Tesla业务部门的首席技术官Steve Scott总结了OpenACC目标：“我们确实想在这一点上做到大幅提高适用性和人们利用GPU的广度和深度。”
Scott表示作为高层OpenACC不会影响执行性能。这来自于他以前在Cray公司做首席技术官的经验，他遇到了基于加速器的指令代码只比手工CUDA编码的性能低5％到10％而已。据他介绍，这是相当典型的。Scott说，有些应用程序甚至做的比他们用CUDA编程要好，这受益于编译器在对某些代码进行优化的能力超越了凡人。在任何情况下，OpenACC的目的是要利用CUDA进行互操作，因此如果需要的话，可以手工调整内核，并与指令代码做无缝连接。
除了PGI和Cray公司，法国的多核软件工具的开发者CAPS公司，也签署了协议支持新的指令。这三家厂商预计在2012年上半年推出支持OpenACC的编译器。值得注意的是OpenACC支持者列表中缺少了英特尔和AMD，不过这也不会阻止PGI、CAPS或者Cray建立支持英特尔和AMD硬件的OpenACC编译器。
PGI和NVIDIA目前向开发人员推出了30天免费试用PGI的加速指令编译器。活动宣传说可以在四周之内将应用性能翻倍。上百位研究人员已经注册了申请试用，
不过对于OpenACC的支持者来说真正终结这场游戏的是将指令纳入到OpenMP标准。因为OpenACC的一部分工作来源于OpenMP，所以就意味着这件事情发生的可能性很高，不过目前没有时间表，但最有可能结合的时间是在2012年某时OpenMP
4.0发布的时候。

1，OpenHMPP和OpenACC是由两个不同的组织发起的。

2，OpenHMPP比OpenACC发展的要成熟。

3，OpenHMPP可以支持多个加速设备，而OpenACC没有这样的指导语句来支持这一点

4，OpenHMPP可以通过某些指导语句来使用想cuFFT一样的库

5，OpenHMPP可以使用更多的硬件细节，例如共享存储器等

目前除了CAPS的编译器之外，没有其它厂商提供支持几乎所有硬件厂商的加速器设备的公司。从市场的角度讲，OpenACC标准始于Nvidia GPU的支持，OpenHMPP始于对所有加速设备的支持。

目前世界上几家企业正在筹谋如何改善现有的OpenACC标准，以将其完善。虽然OpenACC始于Nvidia，但就像OpenCL始于苹果一样，它的最后归属也许是别人！

国内对OpenACC以及OpenHMPP这种基于指导语句的异构编程方式还在起步阶段，慢慢会好起来的。。。。。

引言：

什么是基于指令的移植方式呢？首先我这里说的移植可以理解为把原先在CPU上跑的程序放到像GPU一样的协处理器上跑的这个过程。在英文里可以叫Porting。移植有两种方式：一种是使用CUDA或者OpenCL来重新设计代码，然后使用硬件厂商提供的编译器来编译；一种是使用OpenACC或者OpenHMPP提供的指令集添加到你想使用GPU计算的源代码中的某个位置，让编译器来编译出GPU上执行的代码。后一种方式就是基于指令的移植方式。

例如，下面一个简单的循环：

[cpp] view
plaincopy

1. for (i=0; i<n;i++)
2. {
3. dosomething(i);
4. }

如果你想把这个循环放到GPU上，让每个线程计算一次i的话，可以这样做：

#pragma acc kernels

[cpp] view
plaincopy

1. for (i=0; i<n;i++)
2. {
3. dosomething(i);
4. }

网格化（gridification）：

    这样，编译器拿到加了OpenACC指令的那段代码后，就会把你的循环放到GPU或者其他硬件加速器（例如MIC）上。编译器分析了#pragma acc kernels下面的那个循环，就会根据循环的次数来分配线程数量，这个过程就叫网格化。为什么说是网格化呢？可以这样理解，因为GPU可以启动很多线程，这些线程就像一张渔网一样，可以认为一个网格代表一个线程，所以我就干脆叫这个过程为“网格化”了。

内核（kernel）

在OpenACC里可以这样理解内核：内核就是在协处理器（例如GPU）上被多个线程同时执行的一段代码。如果每个线程都做一个活，岂不是没意思了么？当然不是这样的，他们执行的代码是一样的，但是每个线程可以根据自己的ID号来针对不同的数据做同样的工作，这也就是数据并行的含义。

codelet

使用CAPS的HMPP Workbench编译加了OpenACC指导语句的源代码时，编译器会告诉你codelet产生了。实际上产生了一个CUDA或者OpenCL的源文件，这个源文件中包含了根据你的指导语句生成的CUDA或者OpenCL的源代码。那什么是codelet呢？可以认为codelet就是数据管理+内核。一个codelet要干的事情包括两部分：申请和管理CPU和协处理器之间的存储，还有就是启动在协处理上执行的代码。

work-sharing

这个词可以理解为名词“共享工作”。如果在协处理器上的线程们执行的工作时work-sharing的，那么每个线程可以根据自己的ID在不同的数据上干了相似的工作。这个词是在使用OpenACC或者OpenHMPP移植代码的时候遇到的，它描述的是CPU的串行代码中的状态，例如：

[cpp] view
plaincopy

1. for (i=0; i<n; i++)
2. {
3. a[i] = i;
4. }

在这段代码中，a[i]的计算与a[i]之外的a的元素没有依赖性，所以，每次循环的i可以使独立的完成的，像这样的状态就是work-sharing的。还有例如规约，

[cpp] view
plaincopy

1. s = 0;
2. for (i=0; i<n; i++)
3. {
4. s+=a[i];
5. }

虽然s的计算与i相关，但是细想一下，加法在数学上市满足交换律的，s的每次加a[i]实际上不相关的，你不管以什么顺序加和a[i]到s，解结果总是一样的。所以规约也可以理解为是worksharing 的。