[RFC] 静态图支持计算多流

## 背景与目标描述. 核级并行对mindspore运行时框架提出了静态图计算多流的诉求，通过计算多流来充分挖掘硬件的潜力 通过支持计算多流，计算算子和计算算子可以进行合理资源分配提升Cube资源利用率和Vec&通信掩盖效率，突破现有性能调优瓶颈 ## 建议的方案. ### 现状 框架当前支持计算通信多流和计算通信域多流，总体的思路是将给计算算子和通信算子分配到不同的流上执行，从而获取并行的能力，框架显示抽象了主流的概念，计算算子运行在主流之上，通信算子运行在其他流上 理论上说，框架是支持计算多流的，但存在以下问题 - 框架约定，通信算子会主动增加对主流的同步 这个设计的前提是通信算子相对较少（这也符合绝大多数网络模型），当计算成为一种通信算子时，这个同步的约束，会极大限制计算多流的并发能力 - 框架约定将event封装成虚拟算子嵌入执行序 同上，当计算成为一种通信算子时，event的开销会被成倍放大，导致host bound，算子下发慢，极大限制计算多流的并发能力 ### 任务拆解 #### 去除多流计算算子对主流的同步 去除对主流的同步，多流计算算子可以和主流并发，实现真正的计算多流 #### 优化event数量，去除非必要的event同步 对非必要的event进行合并以及删除处理，消除host bound ## 设计思路 ### 去除多流计算算子对主流的同步  ### 优化event数量，去除非必要的event同步 - 场景 - 跨step/同step - 去除重叠event对  - 场景 - 同step event - 同并event对  - 场景 - 跨step event - 冗余的event对  ## 方案设计探讨 ### 去除对主流的同步 - 简单有效的方案 - 分流 通过分流，避免对主流的依赖 优点：实现简洁，方案清晰 缺点：显存碎片增加，不同流间的显存无法复用 讨论点： **1 分流是仅针对当前计算多流分流还是全局分流** **2 如何处理因分流导致的流间显存无法复用的问题** - 方案二 是否可以通过主动检测来实现多流同步？ 使用DJIT+类似的方案，主动检测内存是否可以复用来提升显存复用率 ### 优化event 此部分优化确定，遍历执行序，记录依赖关系，将重叠的event进行合并，将没有依赖关系的event进行移除处理 ## 模块影响 - mem tracker的内存踩踏检测需要适配 - 可能影响流分配部分的逻辑，需要引入控制边 ## 用例设计 【TODO】 ## CC List @baochong @limingqi107 ### 其他补充信息. ### Before submitting a new issue... - [x] Make sure you already searched for previous [RFCs](https://gitee.com/mindspore/mindspore/issues?q=is%3Aall+label%3ARFC+sort%3Arecently-updated).