最近在使用NNFusion的时候发现Codegen出来的FP16的网络在V100上的性能打不过FP32（甚至要慢一倍以上），但是理论上FP16应该要比FP32有两倍的性能收益才对（V100 Cuda Core的half precision的最大吞吐量是single的两倍，在s9234的slides中看到直接使用half的情况下peak performance其实和single差不多，都是15Tops，但是Cuda Core提供了half2类型，可一次做两个half类型的运算，这是half在CUDA Core上的收益来源；V100卡上的Tensor Core只支持FP16，利用好Tensor Core可以获得非常强的加速，A100卡上的Tensor Core增加更多的精度支持）。
建议阅读的文章：
拿nvprof测试了一下发现主要的性能瓶颈是：half卷积算子的实现速度要比single慢一倍，而这部分运算又占了总体运行时间的绝大部分。
刚开始碰到的问题是这样的：在Azure上开的一台HPC（4块 V100 16G）在运行了大概七八个小时之后，nvidia的显卡会挂掉，具体的表现为nvidia-smi会卡住十几分钟，之后输出No devices were found，但是执行lspci | grep -i nvidia还是可以看到四块显卡好好的挂在上面，这种情况应该直接reboot就可以修复，但是reboot了之后同样的程序运行一段时间之后显卡还是会掉。
A100卡（Ampere GPU Arch）上的Sparse Tensor Core的稀疏加速用的是类似FPGA19上的这篇《Efficient and Effective Sparse LSTM on FPGA with Bank-Balanced Sparsity》的Bank Sparsity的方法，硬件实现比较简单，而且有利于负载均衡。
简单来讲，在Sparse Tensor Core上，对于W*A，把大矩阵W拆分成很多个1*4的小块，然后强制让稀疏度为50%，即每4个元素，去除掉其中绝对值最小的两个值，这种稀疏压缩方式成为(2:4 bank sarsity)，对原本的tensor core也只需要做很小的修改，像下图中加一个mux四个有值的下标来选出与之匹配的矩阵A中的元素进行运算。
how-to-optimiza-gemm 是大家参考得比较多的gemm优化tutorial，本文是在我的MacBook Pro 2019上进行的实践，处理器型号是i5-8257U.
代码在：https://github.com/LeiWang1999/optimize-gemm-on-macbook2019
从来没见过语法像CMake这么烂的DSL，构建项目的时候总是要去查文档，但是查了文档还是不知道该怎么办💢，这里记一下自己常用的一些写法。