2021年的ATC会议所有文章已经放出来，这里放出链接https://www.usenix.org/conference/atc21/technical-sessions，有需要的同学可以去看一看。
作为系统领域的Top之一，ATC上的文章质量颇高，值得一看。
本次会议的Track包括：RDMA、Power and Edge Computing、Correctness and Debugging、Graphs、Blockchain and Security、Machine Learning、Cloud Computing、Training Machine Learning Algorithms、Networks、Storage、OS & Hardware、Persistent Memory and In-Memory Computing、Files、Serverless Computing and Consistency共14个小方向64篇文章（果然是技术大会，什么技术都有）。
由于我一直在AIsys上进行研究工作，所以主要将ATC上设计到的9篇文章进行概要分析，并进行我自己的一些总结，这9个文章分别来自Machine Learning以及Training Machine Learning Algorithms。
一、文章分析
1 Zico: Efficient GPU Memory Sharing for Concurrent DNN Training
本文章面向DNN多任务同时在一个设备上训练的场景。我们都知道DNN需要大量的GPU资源（计算+存储），在多任务同时运行的时候，当前GPU的资源共享做的并不好。目前，GPU的资源共享分为两类，时间共享与空间共享，而时间共享（每个任务均独占GPU）造成了大量的GPU资源浪费，空间共享（英伟达MPS）能更充分利用资源，然而空间共享仍然有很大的弊端，比如当应用对显存需求太大的时候会造成CPU-GPU转移，拉胯性能。所以要降低DNN显存用量。
文章面向DNN中的Feature map（比较大）进行优化。手段是建立大的内存池，供GPU显存的弹性使用。由于DNN前传生成数据，反传释放数据，所以尽量使得俩任务一个前传一个反传。
不过虽然这么想，但是有挑战-CPU与GPU前后分离，不知道GPU运行到哪里了；
本文则提出了Zico，目标是最大化多任务在一个GPU上同时训练时的整体吞吐量。
- Design简要概况
Zico的目的就是为了监控GPU中内存的使用，从而不出现内存不足的情况。
Scrooge scheduler 专门监控显存的使用情况，在新一轮训练开始前，scheduler会检测内存区域正在使用的Tensor的寿命，如果预测如果任务即可发出，这轮训练会超过GPU容量，则再预测任务延迟等待的时间，从而延迟任务发射。
上图就描述了Zico做的事情，预测哪个点可以放。
- Design
在Design的内存管理部分中，文章提到在单个任务情况下，CPU的指令发射与GPU的执行若在一个stream中的话是严格串行的，然而此时的场景为多任务，这就会使得CPU的释放空间的命令发射是乱序的，即我CPU虽然发射了释放命令，但有可能GPU调度到其他Stream上去了，导致命令执行时间会延迟。（原理上还是说GPU的调度会有切换的问题）
为了解决上面内存释放的问题，Zico使用CUDA的Event进行监控。
- Pinpoint
2 Habitat: A Runtime-Based Computational Performance Predictor for Deep Neural Network Training
3 Refurbish Your Training Data: Reusing Partially Augmented Samples for Faster Deep Neural Network Training
本文是我看的第二篇ATC上关于DNN的文章，看完后的感觉是，Emmmm，我要冲了。
当前DNN训练中数据预处理是瓶颈（这里只是follow作者的原始写法，暂时不做评论，虽然我觉得这个瓶颈比较narrow），拖累了训练的整体进程，所以需要加速预处理阶段。现有工作主要是默认方案与Echo。其中，默认方案对所有数据均进行数据增强，严重拖垮性能，如下图（横坐标可以理解为做数据增强的程度，程度越高，数据增强的带宽越低，从而严重拖垮了训练）：
而Echo只做一次数据增强，之后follow。如下图中间的部分：
所以，为了提高性能并且精度不怎么损失，有了本文。
本文的核心思想很简单，加入我们将数据预处理分为四个部分ABCD，此时根据上图c，我们将AB作为Partial Aug，Final Aug是CD操作。所以本文提前将部分数据的AB完成，并cache住。
如上图，通过这种方法，可以省去一部分的数据的部分预处理（省去AB），从而提高性能。然而本文的挑战是，Epoch与Epoch之间，Epoch内的iteration之间都存在不均衡的数据预处理：
1 首先是Epoch间，因为存在部分Epoch会重新将数据进行Partial Aug（AB操作），有的不需要，所以造成一长一短，从而无法很好的与计算Overlap；
2 如下图是Epoch之间的iteration不均衡。原因是buffer中的已经做好AB的数据没有均匀的分配到每一次iteration访问中。
第一个解决办法是将数据分开替换，从而不在同时更新partial数据，如下图；
第二个解决办法是把Cache的数据均匀分到各个iteration中。
