CUDA工具箱中提供了一个很有用的工具叫CUDA profiler，可以用来帮组我们分析CUDA应用程序的性能。通过用CUDA profiler分析我们的应用程序我们可以发现程序的性能瓶颈在哪里，以便更好的实现和组织我们的代码。CUDA工具箱提供两种profiler：
- Visual Profiler：带图形界面的分析工具，可以用来显示CPU和GPU各种活动的时间线，可以自动分析程序的性能。
- nvprof：命令行工具，可以用来收集程序运行过程中的各种性能指标，我们需要根据这些性能指标来分析程序的性能瓶颈在哪里。
1. 两种性能指标
nvprof可以收集两种不同的性能指标，Event和Metric。
- Event： Event存储了kernel运行过程中GPU上各种可数的activity，action和occurance发生的次数，这些都有专门的硬件计数器来记录。每一个Event代表了一个具体的硬件计数器，会在kernel运行过程中记录特定的活动。
- Metric： 每一个Metric都有一个或多个Event的结果计算而来，用来表达一些性能指标。
通过分析这些性能指标，我们可以分析程序的性能。
2. 从GPU的利用率还分析CUDA程序的性能
如果我们想让我们的CUDA程序性能很好运行的很快，一个很直觉的想法是让该CUDA程序可以充分利用GPU，换句话说，CUDA程序的性能可以通过想办法提高GPU的硬件利用率来提升。这里有多个metrics跟硬件利用率有关，特别是achieved_occupancy.
Achieved_occupancy
Achieved_occupancy是一个很重要的性能指标可以用来衡量我们的CUDA程序对GPU的利用率。Achieved_occupancy是一个比例：
从这个公式上我们了解到occupancy是跟warps相关的。那什么是warps呢？在上一篇文章理解CUDA应用程序的结构和执行中我们了解到，warp可以看错CUDA程序的最小执行单元，一个warp将包含32个线程，这32个线程会同时运行，意味着在同一个时钟周期内这32个线程将执行相同的指令，当线程数少于32个时依旧会凑够32个线程组成一个warp执行，只不过有些线程在做无用功。 正是因为一个CUDA应用程序的所需的所有线程将会被组织成warps在GPU上运行，所以achieved_occupancy考察的是warps在GPU上的运行状况。
GPU利用率的物理上限
Achieved_occupancy = 100% 是一个流处理器利用率的物理上限，因为每一个流处理器同一时间所能容纳的warps是有限的，nvidia GTX 970拥有13了流处理器，每一个流处理器所能支持的warps的最大数量是64. 所以当一个流处理器上每一个有效的运行周期内有效运行的warps的平均数量达到64时，achieved occupancy达到100%， 达到利用率的物理上线。物理上限只受GPU流处理器的硬件限制。
GPU利用率的理论上限
上面我们提到了GPU利用率的物理上限受GPU硬件的限制，那GPU利用率的理论上限则同时受目标设备，kernel的实现，以及kernel加载时线程的配置参数所影响。一个流处理器上所能运行的warps的个数受限于这个流处理器上分配的thread blocks的个数，而一个流处理器上所能容纳的thread blocks个数也是有限的，对于GTX 970来说，每一个流处理器最多容纳32个thread blocks。32个thread blocks只是GTX 970能容纳的上限，而实际情况要复杂的多，每个流处理器所能容纳的thread blocks个数还要受该流处理器上共享内存的大小，寄存器的大小，以及每个线程对寄存器和共享内存的使用情况所决定。
是每个线程用来存储本地变量以减少内存读取时间。每个流处理器上的寄存器的个数是有限的而且是被所有该流处理上的线程所共享的。
-
取决于kernel被加载时线程的配置参数
-
取决于kernel代码的实现
所以在我们加载一个kernel的时候，每一个thread block所需要的寄存器的个数也就确定了。当一个thread block被分配到流处理器上时， 所需的所有寄存器要同时一次性分配给该thread block。 因此当一个thread block消耗过多的寄存器时，那么该流处理器所能分配的thread block的个数就会变少，如果thread blocks中包含的线程数少，那么流处理上所运行的warps就也会变少。假设一个GPU上，只有一个流处理器，一个流处理器上总共有100个寄存器，kernel运行成产生20thread blocks，每一个thread block都需要消耗60个寄存器，那这个流处理最多每次只能容纳一个thread block，因为两个thread blocks需要120个寄存器。 因此这20个thread blocks需要按顺序在该流处理器上运行20次。每个thread block需要运行10秒那一共需要运行200秒。且每次有40个寄存器是空闲的，会造成资源的浪费。如果一个thread block消耗50个寄存器，那每个流处理器每次可以同时执行2个thread blocks，20个thread blocks每次运行两个，运行1o次一共消耗100秒。
是用来给每个thread block里面的线程进行通信的，通过读写相同区域的内存达到数据交换的目的。像寄存器一样，流处理器内的共享内存的大小是固定的，当分配一个thread block到流处理器上时，除了分配需要的寄存器，也需要分配所需的共享内存。因此我们可以说处理器分配资源时是以thread block所需的资源为最小单元的。当一个流处理器没有足够的资源分配给thread block时，thread block就不会被分配到该流处理器，即使该流处理器还有很多未使用的资源。
所以每当一个kernel被加载的时候，每一个流处理器上能分配的thread blocks的个数就已经确定了因此warps的个数也就确定了，基于寄存器和共享内存的限制，每一个流处理器上分配的warps的个数会小于等于这个流处理器所能支持的最多的warps的个数。因此相比于设备的物理上限，当一个kernel和要运行的设备确定的时候，这个kernel对GPU利用率的理论上限也就确定了。但是实际运行过程中，achieved_occupancy，是要小于理论上限的。因为achieved_occupancy考察的是每一个有效的时钟周期内平均的有效的warps的个数。从程序开始执行到所有的任务完成之间所有的时钟周期为有效的时钟周期。一个warp从其线程开始执行到其中的所有的线程都退出为止，我们称这个warp为一个有效的warp，意味着当一个warp执行完其最后一条指令，这个war就不再是一个有效的warp。一个thread block是有效的直到其中所有warp变得不在有效。当一个thread block中的所有warp完成其工作，这个thread block变得不在有效的时候，所有分配给该thread block的资源才会被释放。于是有一种情况就是，一个thread block有50个warp，其中49个完成了工作，只有1个还在继续工作，则这个warp工作的这段时间是有效的时钟周期，而这段时间真正有效的warp只有一个。会拉低所有有效时钟周期内有效的warp的平均个数。因此有两个非常重要的因素将会影响到achieved_occupancy:
- unbalanced workload within a block: 如果一个thread block里面所有的warps不能同时完成，我们就说这个thread block的工作量是不平衡的。当warps间的工作量不均衡的时候，有一些warp提前完成任务变成无效的warp，它们需要去等待其他warps完成工作，但是这些无效的warp还是会占用资源直到所有的warps都完成任务退出。因此即使空闲的资源可以分配给未执行的thread block，但是这些资源还没有被释放，无法分配。因此设备的利用率会很低。
- unbalanced workload between blocks:如果一个thread grid里面所有的thread blocks不能同时完成，我们就说thread blocks间的工作量不均衡。因为一个kernel要所有的thread block完成任务才能退出，加载另外一个kernel。所以说如果到最后只剩下一个thread block在运行，那整个GPU大部分的流处理器都要闲置去等这个thread block完成任务，整个kernel才会退出。这会导致整个GPU的利用率很低。
