基于RDMA GPUDirect技术的NCCL XCCL库体系结构效率问题疑补

2023年发布了两篇博文<<异数OS-织梦师-大禹(九)奔跑在GPU上的异数OS>> <<为何一座国产超算中心打不过8张nvidia A100计算卡？>>后收到不少业内同行的质疑，大部分质疑认为GPUDirect RDMA和NCCL在效率上已经足够，没有必要再做一个GPU上的操作系统来挑战行业惯例，所以这篇文章整理出GPUDirect RDMA NCCL的效率问题加以详细补充解释。

1. GPUDirect RDMA 虽然不需要CPU完成DMA操作，但却需要CPU上的应用软件通过NCCL库发起和调度DMA，GPU不能独立发起DMA，因为他没有一个GPU上的操作系统，这会遇到上文中提到的CS结构的效率问题。
2. NCCL 是MPI集合通讯库的复制，但实际上并不是复制，NCCL并不是独立运行在GPU上，因为GPU上没有操作系统，效率上不一定比CPU上的MPI库更有效率，MPI是建立在操作系统IPC基础上，它只需要CPU与CPU的IPC通讯，计算任务可以与通讯任务混合编写，通过多进程任务类型分组可以弥补覆盖通讯阻塞带来的计算效率损失，计算与IO混写一个是能降低算法复杂度，另外也能降低IO与计算任务间的延迟，这有利于L2 L3加速，而NCCL就比较复杂了，他需要CPU端应用在NCCL基础上实现一个IO延迟性能不高的类操作系统，将通讯操作独立任务化，与计算kernel分离，使用并行的stream来应对覆盖延迟效率问题，并行stream需要考虑阻塞通讯操作带来的上下文回环锁依赖问题，同时计算kernel与通讯任务分离到不同的stream还会带来不确定较大的计算延迟，这会带来类似循环雪崩的冲动迫使GPU需求更多的潜伏期缓冲内存，也因此使得任务无法有效利用GPU的 L2 加速，如果不使用并行的stream队列，则会面临CS结构的效率惩罚。
3. NVLink的优势是缓存一致性的共享内存，这使得他能最大限度降低编程算法复杂度，使得算法表达不需要考虑通讯任务，可以利用L2加速，并且效率优化可以通过编程手段解决应对，共享内存相比NCCL还有减少内存副本减少中间缓存的作用，这可以大大降低显存开销成本，虽然GPUDirect RDMA可以建立在NVLink基础上，但GPUDirect RDMA 依赖NCCL 的情况下在效率和编程复杂度上都将面临重大挑战，这可能是Nvidia的一个扮猪吃老虎的烟雾弹战略，利用同行抄袭NCCL 的低效方案来降级掠杀同行。
4. Roce RDMA自身存在若干问题，RDMA的pcie硬件通常不强大，并发性能也不高，在实现双边 Send Recv时，IOPS性能也不如传统千兆网卡，而双边Send Recv是实现MPI IPC的基础，很多人说RDMA 的单边read write都是做到30M,但单边操作并不能帮助实现MPI的IPC机制，因此主要用于共享内存场景，但read write的iops与NVLink宣称的40GT还有3个数量级的差距，在带宽上也存在1到2个数量级的差距，在共享内存编程模型上显然不如NVlink有竞争力。

结论：NCCL由于存在CS双惩罚情节，GPUDirect RDMA虽然有点强大，但被NCCL拖后腿，在编程复杂度以及效率上都不能替代MPI，要解决效率问题就需要在GPU上实现异数OS操作系统，利用GPUDirect RDMA实现高效率的异数OS IPC，才有望真正实现GPU上的高效MPI，当然MPI未必就很高效，毕竟MPI是通讯阻塞的，面对这个问题，使用GPU上的异数OS 流水线方案来应对通讯阻塞方案将会是更简单更有效率更可控的选择。