基于 GPU 平台的 GeoBenchmark 优化 - …

《基于 GPU 平台的 GeoBenchmark 优化 - …》由会员上传分享，免费在线阅读，更多相关内容在学术论文-天天文库。

1、基于GPU平台的GeoBenchmark优化PB11011003贺松涛1，总览最后一次实验选的是对GeoBenchmark的优化，平台是计算能力3.5的KeplerK20c。在8000*8000的数据规模下最后的最优结果是1.85s。主要的优化手段包括sharedmemory，消除分支语句，优化grid，block结构，使用Kepler新增的只读Cache等。这些优化均是依据Kepler架构进行设计的。接下来是具体的优化方法。2，之前基于mic的算法优化，转置等在这里同样沿用，不再多少。3，消除分支语句

2、Mic和GPU的结构不同，GPU对于一些线程内的分支相对来说更敏感，而且GPU可以通过计算来修补这些分支，而在MIC中，则不如保留分支。例如if(oiznx)biased=nx;这样的语句，修改成通过计算完成的语句。biased=biased+(oiznx)*nx+(biased<=nx)*biased;在求和计算部分，由于两个for循环的起始地址都是变量，这里应尽量使得计算规整。因此将两个for循环合并成一个。并且通

3、过计算的方式消除分支。之前的两个for循环for(iy=bias;iy=bias)*data[oiz*nx+iy-bias]+(iy

4、ta[oiz*nx+iy+bias];}也就是利用了c语言中条件判断在真时返回1，假时返回0的特点，来避免分支，同时也使得各个线程之间的负载是平衡的。4，sharedmemory在geobenchm中，在行列转置后的算法中，计算某一行时，是将其之后的一些行加到这一行上，因此，记录这一行值的时，可以使用sharedmemory。当然，这一行数据如果全部存下来需要32KB的大小，为了充分的利用Kepler架构的资源，我们把每一行分成两部分分别进行计算，也就是每一个block需要16KB的sharedmemo

5、ry。这样，就可以在一个SMX上同时发射3个block，因为sharedmemory最多是48KB，如果是一个block需要32KB则只能分配一个block，会浪费大量存储和计算资源。5，只读存储器缓存Kepler架构中新增了一个48KB的只读存储器缓存，由于在程序中，data数组是只读的，因此通过添加编译制导符号，使得data数据使用这个48KB的只读缓存。事实上，因为分配了48KB给sharedmemory，因此传统的L1Cache只有16KB，因此这一优化可以很好的提升性能。6，优化gridblo

6、ck结构事实上，这一块是最关键的优化。首先是thread数量的分析，由于这个程序需要大量的访存，也就是存在着大量的长延时操作，因此需要尽量多的线程去相互隐藏彼此的延时，因此线程数应尽量多。当然，也并不是越多越好，过多的线程会导致线程执行的周期过长，从而影响局部性，造成一定的性能损失。另一方面，线程数的多少还应是计算规模的因子，也就是可以被整除，否则在没有同步机制的情况下会导致线程负载失衡，从而影响局部性。因此综合考虑这些因素，以及实验结果，选择block的大小为500（能被8000整除）。下一步就是gr

7、id结构的组织，其实在前面sharedmemory优化中已经阐明，采用8000*2的结构，将一行数据分成两部分进行计算，每部分都是需要16KBsharedmemory，这样可以充分利用全部48KB。但事实上这并不是最优的配置，因为每个SMX可以同时为4个block发射指令（quadwarpscheduler）这里只是用了三个，但由于数据刚好是8000，如果分成4个block或更多，实验表明反而会影响性能。因此这里最终采用配置：Grid8000*2Block5007，优化结果以及nvvp评估分析按照nvv

8、p的分析，程序整体状况比较均衡，使用情况勉强及格。从带宽情况可以看出，TextureCache的带宽比较高，说明之前对只读存储的优化发挥了很大的作用。这里的TextureCache实时上包括了Kepler新增的只读数据缓存。而由于没有使用纹理存储器，因此这些吞吐量可以看成是全部的只读数据缓存的吞吐量。对于最终的运行时间，在最佳情况下是1.85s，然而由于没有采用同步机制，波动会比较大，最慢可达到2.8s左右，如果采用了同步机制则波动基本消除