CUDA、BSGP及SPAP调研报告 - 肖韬 南京大学计算机系.ppt

* * * * * * * * * * * * * * * * * 周昆教授的GPU相关项目调研报告肖韬 南京大学计算机系 2010.10.28 CUDA?是一种由NVIDIA推出的通用并行计算架构，该架构使GPU能够解决复杂的计算问题。 使用经过扩展的C语言来为CUDA?架构编写程序。 与CPU相比，GPU有更多的晶体管被用于数据处理。 通用并行计算模型 单指令、多数据执行模式 (SIMD) 所有线程执行同一段代码(1000s threads on the fly) 大量并行计算资源处理不同数据 data centric model: 数据被组织成很多的stream kernel: 并行地作用于每一个流中的数据 stream/kernel抽象模型把数据间的依赖性暴露给了编程者。 第一个基于BSP的GPU编程语言 在GPU上进行通用计算的类C的串行编程语言 只需提供少量的信息(即barriers)来描述GPU上的并行任务 易于编写、理解、维护 不牺牲运行性能(与CUDA语言编程相比) BSGP编程模型 不能与GPU的stream processing模型直接对应，因此需要BSGP编译器将BSGP的源代码转换为GPU的stream代码 这就必须解决两大挑战： barrier synchronization的同步问题 怎样生成高效的stream code 开始BSGP编程 BSGP中的几个基本概念 barrier图示 所有的同一个kernel的所有线程执行流都要在同一个 barrier处同步 在流处理模型中，barrier只有一种形式：等待kernel终止 在某一个kernel的内部无法进行barrier 所谓collective operation，即指所有线程必须同时进行的操作 求prefix sum的图示 collective scan spawn(n) { statements; } n个线程将被创建来并行地执行statements语句 有些操作(如资源分配以及kernel配置)必须由外界来进行 借助于require块，允许在BSGP代码中插入CPU控制代码 运行时，CPU控制代码将先于superstep被执行 其他的特征 使用fork和kill来生成和销毁线程 线程通讯机制 原语操作(reduce, scan , sort等) 线程之间的通讯只允许发生在barrier处 忽略processor间数据的局部性 以上两点很好地符合了stream processing的特点 1. Inline all calls to functions with barriers 2. Perform optimizations to reduce data dependencies 3. Separate CPU code and GPU code. Generate kernels and kernel launching code 4. Convert reference to CPU variables to kernel parameters 5. Find all values needing to be saved, i.e., values used outside the defining superstep 6. Generate code to save and load the values found in Step 5 7. Generate temporary stream allocations SPAP — Same Program for All Processors. 目前的系统上有多核CPU与多核GPU 希望能够充分利用这种异构型的计算能力 不同的处理器有不同的计算模型(从指令级别到算法级别) 例如，在x86处理器上线程的总数最好与CPU核的总数相等以避免上下文切换；但是在nVidia的GPU上线程数越多越好。 使用容器(container)将有关处理器并发和性能相关的方面抽象了出来 每一个container是一个具有类似于STL接口的原语(primitive) 为每一个container提供了与特定处理器相关的最优化实现 container的行为一致性(behavior consistency) 从编程者的角度来看，一个SPAP container的行为跟其对应的串行程序(counterpart)的效果相同 编程者将计算任务表达为若干个work units SPAP将这些work units动态地划分为若干个子集