最近在使用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增加更多的精度支持)。

建议阅读的文章:

聊聊 GPU 峰值计算能力

A100 Tensor Float 32 性能实测

拿nvprof测试了一下发现主要的性能瓶颈是:half卷积算子的实现速度要比single慢一倍,而这部分运算又占了总体运行时间的绝大部分。

Digilal DesignEEEE

Ночной дозор by Foto Vishnya / 500px | Облака, Пруды, Зеркало

刚开始碰到的问题是这样的:在Azure上开的一台HPC(4块 V100 16G)在运行了大概七八个小时之后,nvidia的显卡会挂掉,具体的表现为nvidia-smi会卡住十几分钟,之后输出No devices were found,但是执行lspci | grep -i nvidia还是可以看到四块显卡好好的挂在上面,这种情况应该直接reboot就可以修复,但是reboot了之后同样的程序运行一段时间之后显卡还是会掉。

Digilal DesignEEEE

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中的元素进行运算。

image-20220220210511461

Digilal DesignEEEE

从来没见过语法像CMake这么烂的DSL,构建项目的时候总是要去查文档,但是查了文档还是不知道该怎么办💢,这里记一下自己常用的一些写法。

CMake