Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hpda::processor::split 的实现不符合HPDA文档中三种状态转移的抽象 #18

Open
weixiao-zhan opened this issue Aug 14, 2023 · 3 comments

Comments

@weixiao-zhan
Copy link
Contributor

当前split算子会在内部为每一个下游算子生成一个rawdata实现的缓存队列,但是rawdatasplit之间的数据流是通过push操作,即rawdata.add_data实现的。该数据流不被hpda::engine所知。
所以在hpda::engine的视角,split算子是计算图的一个输出算子,rawdata实现的缓存队列们是计算图的extractor。

对于copy split,虽然实现不符合HPDA文档的状态转移,但是不会导致调度错误
对于从hpda::processor::split衍生的hash split算子,则会有问题:由于hash split不一定能立刻给栈顶的rawdata产生输出,hpda::engine会误以为栈顶的rawdata算子已经达到终止状态,从而不在唤醒该缓存及其下游算子,导致一些数据不会流过hash split的下游算子。

@weixiao-zhan
Copy link
Contributor Author

fix suggestion
注:这段代码不work,帮一起看看哪有问题

@AthrunArthur
Copy link
Member

AthrunArthur commented Jan 26, 2024

当前split算子会在内部为每一个下游算子生成一个rawdata实现的缓存队列,但是rawdatasplit之间的数据流是通过push操作,即rawdata.add_data实现的。该数据流不被hpda::engine所知。 所以在hpda::engine的视角,split算子是计算图的一个输出算子,rawdata实现的缓存队列们是计算图的extractor。

split算子内部生成的是一个为下游每个算子准备的输出算子,而不是一个rawdata实现的队列,每个输出算子确实使用了rawdata实现,但是因为每个输出算子都加入到了hpda::engine中,且每个输出算子的前趋节点也指定为了相应的split算子,所以其实每个split内部的输出算子也是和其他算子一样参与调度的,是被hpda::engine所知的。

对于copy split,虽然实现不符合HPDA文档的状态转移,但是不会导致调度错误 对于从hpda::processor::split衍生的hash split算子,则会有问题:由于hash split不一定能立刻给栈顶的rawdata产生输出,hpda::engine会误以为栈顶的rawdata算子已经达到终止状态,从而不在唤醒该缓存及其下游算子,导致一些数据不会流过hash split的下游算子。

这个hash split的代码我没有看到,能发一个链接吗?

@AthrunArthur
Copy link
Member

fix suggestion 注:这段代码不work,帮一起看看哪有问题

这个代码的问题在于split内部使用了多个processor,而不是之前的rawdatahpda::engine处理processor时,需要看其前趋节点是否有输出,所以split的数据会被第一个processor消耗,但后续processor查看split时,其中的数据已经消失,所以hpda::engine会错误的认为后续的processor都没有数据可用。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants