GPU优化
对于GPU的优化，我们有不同的方法，比如挑选一个好的并行算法、遵循高效的内存存取原则、优化存储体冲突（bank conflicts）以及位操作微观优化，后两者是两个ninja topic，意味着很多时候在这方面投入精力进行优化并不能得到很大的效率提升，因此也不作为重点讨论。
下面讲一个GPU中常用的优化模式，称为APOD，一个好的GPU程序总是不断在分析（Analyze），并行化（Parallelize），优化（Optimize）与Deploy（应用）之间循环衍进的，我们往往会注重并行化跟优化的过程，但是需要注意的是应用与分析也是非常重要的一环，应用是观察最后能得到多少实际效果的检验，而分析则有利于我们做更进一步的优化。
我们还需要注意需要把优化热点（hotspot）放在不同的程序段上，例如我们对某一个程序段优化到一定程度以后再对它进行优化取得效率的提升将大大降低，因此这个时候继续选择这个优化热点并不是一个很好的选择，而跟聪明的方法是把热点放在其他程序段上
例子
下面让我们来看一个例子来阐述如何对一个程序进行优化，我们的任务是将一个矩阵内的元素进行转置操作。
下面我们来比较三种方法的运行时间，第一种方法是串行的方法，我们将转置的操作放在同一个线程中，用两层循环的形式来达到目的；第二种方法是按行并行化，意思是分配N个线程（假设矩阵为N×N），每个线程处理N个元素的转置；第三种方法是每个元素都开启一个线程来做转置操作。下面是最后的运行结果。
下面让我们想想这个0.67ms真的是达到速度的极限了吗？限制运行速度有两个因素，一个是对数据执行计算的时间，一个是内存存取的时间。我们现在所做的工作是将计算的时间压缩到了最小，那么内存存取的时间呢？我们可以通过deviceQuery这个内部接口来查看设备的吞吐量信息。我们可以分析得到我们的带宽利用率并不是特别高（下面计算中4代表每个元素有4个字节，2代表存储两次操作）。
提高global write efficiency
那我们怎么进行改进呢，很容易就想到coalescing。下面我们用nsight工具中的NVPP可以进行时间以及利用率的分析。我们可以看出方案三全局数据读取利用率（global read efficiency）达到了100%，但是全局数据写入利用率（global write efficiency）只有12.5%，这是为什么呢？原因就是我们实现了coalesced read, scattered write。在看代码之前我们要讲一下wrap的概念。之前我们讲过了一个GPU中有很多个SMs（streaming multiprocessors），而一个SM中有很多个SPs（streaming processors），现在架构中一个SM中一般有8个SP，而SP运行线程的时候是以wrap为单位的，一个wrap中一般有32或16个线程，这些线程是完全并行运行的，只有当一个wrap运行完之后下一个wrap中的线程才会进入。而wrap中的线程是以x坐标为索引的，意思就是如果一个block中的线程是二维的（32×32），那么我们将取第一行32个线程作为一个wrap，然后取第二行32个线程作为一个wrap，以此类推。正是如此，当有一个wrap进行操作的时候，我们可以让其中的相邻线程采用coalescing的模式来提高存取效率。让我们来看看第三种方案其中最核心的代码。
我们可以看出对于in数组而言，相邻的i对应的是相邻的线程，因此可以采用coaleced read模式，而写入out数组的时候相邻的i对应的线程是不相邻的，因此写入利用率会比较低。我们来看看如何解决这个问题。我们想到的方法就是将矩阵分为一个个块（tile），将它以行为索引，用coalesced read的方式读取到shared memory中，然后在shared memeory中做转置，之后再以行为索引用coalesced write的方式写入global memory中。
以下是核心代码，请注意在写入shared memory的过程中我们直接以转置的顺序写入了，以便节省一个同步操作，我们接下来会讨论同步操作对程序运行效率的影响。
减小平均时延
在如上操作以后以后我们会发现我们的带宽利用率还是很低，那这到底是什么原因呢？我们首先来看一下限制GPU带宽的原则，叫做Litter's Law。它阐述了带宽、传输的字节与延时的关系。我们可以把传输的过程看做一个管道，因此当很多个线程同时在进行内存存取操作的时候才能够将管道填满以便提高传输的字节。对于第三种方案来说，每一个矩阵中的元素都开启了一个线程，那么管道必然不会很空，在这种情况下还有很低的带宽，那么问题必然是出在了平均时延上。
