问题1(3)：性能对比

经过上一篇讨论的方案，老师让我再试了试别的优化，并且我这里还进行了一些别的学习，知道了更多性能相关的知识，这里把我们的实验结果重新书写一下。

待解决的问题

我其实这里还有不少问题：

• 两个stream并发的这种方法与后面用一个kernel融合了两个操作的方法在调度上是否是同样逻辑的？既然都是分成多个program,在block级别上调度，那么在SM视角上是不是同样的？不同逻辑，cuda stream应该是更粗粒度的调度，没办法控制到CTA到SM上的排列。而使用Hfuse的方法基本上是可以在SM级别上进行控制的，也就是所谓的理想情况下block可以映射到一部分SM上
• 考虑two range和four range的方案，按道理说是SM数量>tile数量才能取two range,反之用four range,但是我们如何取这个range来保证相同算子运算映射到同样部分SM？这应该是硬件特化的吗？如果要这么做，肯定是需要硬件特化的。但是按照我们的思路是通过tile数量进行划分的，也就是half_split（two range）：range_sizes = (op1_tiles, op3_tiles)，分别等于op1_tiles = ceil(M/16) * ceil(R/128)、op3_tiles = ceil(M/16) * ceil(N/128)。interleaved（four range）：先把每个算子的 tiles 均分成两段：op1_split = split_evenly(op1_tiles, 2)、op3_split = split_evenly(op3_tiles, 2)，然后组成 op1 / op3 / op1 / op3 四段，余数优先分到前面的段
• 矩阵拼接的办法要算的tile总数应该与两次分开launch一样，这样性能有什么区别？不知道
• 取r=8时，算子一的计算太少，影响几乎可忽略不计，能查到的问题几乎都是kernel launch的时间。这时应该提高r进行查看吗？这个完全是因为参数量就不适合应该取更多的参数组合进行尝试。
  • 当r太小的情况，根本就塞不满SM,但是计算的时间也非常小，这样的话融合几乎看不出来比较。
  • 当r太大的情况，两个算子本来自己都可以填满SM,waves都能达到8了，融合的意义也不是很大
  • 只有两个算子都中等大小的时候比较明显，比如A100有108个SM，那么当两个op都是50个block的时候效果会是50%的效能提升（理论上）。
• 效能应该是使用SM active吗？这里应该是让每个SM上reside的block达到上线才是满利用，而不是每个SM都在跑都好吗？减少Bubble到底应该看什么指标？ 自己去看ncu文档

更多问题

• horizontal fusion论文可以看一下
• flash attention