Xiaoyu Xu
Xiaoyu Xu
> 针对 [#8866 (comment)](https://github.com/Oneflow-Inc/oneflow/pull/8866#discussion_r955574611) 这个问题。与后江开会讨论结果： > > 1. python层的flow.Stream名不副实。它其实在导出flow.StreamSet概念，即这是一个跨StreamType/DeviceType的概念，与一般用户理解的stream从属于device这一常识相去甚远。 > 7. PipeLine，Device，StreamType这三者唯一确定一个vm::Stream对象。 好像和通常理解的 PipeLine （流水线） 也关联不大，更接近 c++ std::thread 的抽象，flow.Thread？ _Thread，Device，StreamType这三者唯一确定一个vm::Stream对象_
> > > 针对 [#8866 (comment)](https://github.com/Oneflow-Inc/oneflow/pull/8866#discussion_r955574611) 这个问题。与后江开会讨论结果： > > > > > > 1. python层的flow.Stream名不副实。它其实在导出flow.StreamSet概念，即这是一个跨StreamType/DeviceType的概念，与一般用户理解的stream从属于device这一常识相去甚远。 > > > 2. PipeLine，Device，StreamType这三者唯一确定一个vm::Stream对象。 > > > > > > 好像和通常理解的 PipeLine （流水线） 也关联不大，更接近...
> experimental 试验性的工具类 torch 一般是放到 utils.xxx 下面，稳定后再升级到二级命名空间下、或者一级命名空间下。 之前的实验性功能命名空间 experimental 也都已经删掉了
这里有个问题要讨论下： ``` # a_tensor a_tensor += b_tensor # inplace_op_0 c_tensor = a_tensor * 3 # op_1 ``` ``` a_tensor -> inplace_op_0 \ \ + -> op_1 ``` 之前 inplace_op_0 和...
> > 这里有个问题要讨论下： > > a_tensor -> inplace_op_0 -> op_b > > 之前 inplace_op_0 和 op_b 可以没有顺序关系，但是有了 inplace 后，顺序关系才能保证正确性了 > > 这里格式好像有点问题，op_b 是在inplace_op_0输出之后执行的么？ 更新了格式
> > > > 这种并发的read 确实会造成正确性问题，但是现在的问题有两个 > > 1. 对于UserOp，这种并发的read的情况可能会发生么？ 是有可能发生的。这个地方请 @chengtbf 也看下吧 > 2. 如果 1 会发生，目前框架对于inplace的操作是否限制了其并发的操作，比如让它能被并发的读写吗，这里有两块代码，不知道是不是做这个的： > > > https://github.com/Oneflow-Inc/oneflow/blob/master/oneflow/core/framework/op_interpreter/lazy_op_interpreter.cpp#L924-L935 这个印象中是 inplace 时，不让对该输入做 boxing > > https://github.com/Oneflow-Inc/oneflow/blob/master/oneflow/core/framework/op_interpreter/lazy_op_interpreter.cpp#L954 这个是现在...
> 如果继续支持 int str 等其他类型的输入的话，还需要额外处理下 （本质上对于这些值就是 warning + 直接返回）。想确认下这样做是不是恰当的？ 是没问题的，之前只是提供了类型，ArgsTree里面需要自己看一下类型，然后根据类型做处理就好
> 其他 rank 上的输入为 None 可以先拿 rank 0 作为测试。 测试成功后再改的更为通用，就是拿非 None 的，向 None 的 Rank 进行发送，应该是更通用的。这里其实有个准确的判断标准，就是 placement 里面包括的 rank，向 placement 里面不包括的 rank，做发送。
``` P = flow.placement("cpu", ranks=[0, 1]) SBP = flow.sbp.split(0) global_x = flow.ones((2, 2), placement=P, sbp=SBP) flow.to_global(global_x, placement=P, sbp=SBP) ``` 这里 to_global 的输入 global_x 的 sbp 和要转换的的 sbp 是一样的，那这里按说就是一个可以直接返回的操作。 在两个 rank...
这个需要结合一个具体的例子来看看，看这种两阶段的 to_global 配置是否普遍、是否可以作为一种通用的功能。 如果这种使用模式非常不规整，可能还是需要让用户在 tensor 级别去做。