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

[async] Add element-wise info into TaskMeta for fusion #1884

Merged
merged 7 commits into from Sep 21, 2020

Conversation

xumingkuan
Copy link
Collaborator

@xumingkuan xumingkuan commented Sep 20, 2020

Related issue = #742

Changes:

  • Add std::unordered_map<SNode *, bool> TaskMeta::element_wise
  • Refactor AsyncStateHash into std::hash<AsyncState> because I think we don't need other hashes of AsyncState
  • Fix typo "fusable" -> "fusible"

Question:

  • How does the element-wise info affect mask/list states?

[Click here for the format server]


@codecov
Copy link

codecov bot commented Sep 20, 2020

Codecov Report

Merging #1884 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master    #1884   +/-   ##
=======================================
  Coverage   43.19%   43.19%           
=======================================
  Files          44       44           
  Lines        6330     6330           
  Branches     1092     1092           
=======================================
  Hits         2734     2734           
  Misses       3426     3426           
  Partials      170      170           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f2a798d...427453b. Read the comment docs.

Copy link
Member

@yuanming-hu yuanming-hu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome!! LGTM.

How does the element-wise info affect mask/list states?

Great question. The short answer is we don't need to worry about it.
If a write access is element-wise, the activation will be demoted here:

void visit(GlobalPtrStmt *stmt) {

So by the time you are doing the is_element_wise test, whether a task needs list generation/gc/mask state output is already determined. We don't need to handle that once more.

(Sorry I didn't notice we already have a similar implementation of is_element_wise there - maybe we can unify two implementations sometime in the future.)

taichi/ir/ir.cpp Outdated Show resolved Hide resolved
taichi/ir/ir.cpp Outdated Show resolved Hide resolved
xumingkuan and others added 2 commits September 21, 2020 14:35
Co-authored-by: Yuanming Hu <yuanming-hu@users.noreply.github.com>
@xumingkuan
Copy link
Collaborator Author

xumingkuan commented Sep 21, 2020

If a write access is element-wise, the activation will be demoted here:

void visit(GlobalPtrStmt *stmt) {

(Sorry I didn't notice we already have a similar implementation of is_element_wise there - maybe we can unify two implementations sometime in the future.)

Interesting! It looks like the element-wise check in flag_access also includes a sparsity check. For example, if x and y have different shapes on the parent sparse SNode (x is smaller than y) or they have the same shape but their parent sparse SNodes are different, y will not be considered element-wise in

for I in ti.grouped(x):
    y[I] = 1

(y[I] needs activation here). However, for fusion, we can consider the task as element-wise on y.

A fusible example:

x = ti.field(ti.i32)
y = ti.field(ti.i32)
ti.root.pointer(ti.i, 4).place(x)
ti.root.pointer(ti.i, 8).place(y)

@ti.kernel
def foo():
    for i in x:
        y[i] = 1

@ti.kernel
def bar():
    for i in x:
        y[i] = 2

foo()
bar()

ti.sync()

Now I think the mask/list states have the same criteria as value states here -- if task a has an edge to task b (struct for or range for tasks), no matter which type the edge's state is, only if both tasks are element-wise on the edge's SNode, can a and b be fused.
Now I think it's fine to not check mask/list state edges -- if there are these edges, there must be value state edges too. Mask state edges can be of parent SNodes, so it would be easier to check value state edges directly.

@xumingkuan
Copy link
Collaborator Author

Why Some checks haven’t completed yet -- Build and Test (CPU) (ubuntu-latest, 3.6, OFF) Expected — Waiting for status to be reported?

@xumingkuan xumingkuan merged commit 9a23ecd into taichi-dev:master Sep 21, 2020
@xumingkuan xumingkuan deleted the element-wise branch September 25, 2020 05:50
@yuanming-hu yuanming-hu mentioned this pull request Sep 26, 2020
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

Successfully merging this pull request may close these issues.

None yet

3 participants