Skip to content

Graph partition with broadcast logic#280

Merged
jjsjann123 merged 9 commits into20_7_6_develfrom
graph_partition_with_broadcast_logic
Aug 13, 2020
Merged

Graph partition with broadcast logic#280
jjsjann123 merged 9 commits into20_7_6_develfrom
graph_partition_with_broadcast_logic

Conversation

@jjsjann123
Copy link
Copy Markdown
Collaborator

@jjsjann123 jjsjann123 commented Aug 10, 2020

Update partition logic resolves #190

  1. prevents partition that results in divergent broadcasting rule applied on a single tensor/TensorView.
  2. prevents output tensor broadcasted inside fusion.

@jjsjann123 jjsjann123 changed the base branch from disable_bcast to 20_7_6_devel August 10, 2020 19:58
@jjsjann123 jjsjann123 force-pushed the graph_partition_with_broadcast_logic branch from 0b3c08f to 316ae16 Compare August 12, 2020 22:28
@jjsjann123 jjsjann123 changed the title [WIP] Graph partition with broadcast logic Graph partition with broadcast logic Aug 13, 2020
@jjsjann123 jjsjann123 requested a review from csarofeen August 13, 2020 12:08
Copy link
Copy Markdown
Owner

@csarofeen csarofeen left a comment

Choose a reason for hiding this comment

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

I would like to go though this logic a little more carefully with you in the future, but don't see any major issues except one comment. Approve for now.

self.assertGraphContains(t_jit3.graph_for(x, y, 2.0), FUSION_GROUP)

# Testing partition logic that is capable to avoid creating unsupported
# broadcasting semantics in CudaFusionGroup
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

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

Seems this test is figuring out what it can generate, not that it avoids unsupported cases.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

That is true.
If the partition does create unsupported case, it would error out. So it sorta checks the right thing.
This is not ideal tho, I can put some more lines there to traverse the fused graph.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Just FYI, getting the bailout subgraph is trickier than what I thought it would be. I'm going to split the test into two instead of using the BailOut thing 🤦

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

I'm going to leave it as-is for now.
Realized that relying on bailOut test is a poor strategy. I'll do a follow up PR to overhaul some related tests as well.

n->outputs().size() == 1,
"not expecting multiple outputs from a node, graph partitioning logic needs to be updated");
// assumes that if output is not a tensor type, it's not broadcasting
if (auto out_type = n->output(0)->type()->cast<TensorType>()) {
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

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

Is this line right?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

I don't spot anything wrong with it.
We assert on single output the line above and we check to see if the output is TensorType before we start checking broadcasting.

Are you suggesting to assert on TensorType instead? I didn't do that in the hope of making the code future proof-ish, in the case we might have nodes that extract information of the tensor like aten::size()

// exists in input `shape`
for (const auto& opt_size : shape) {
// TODO: not sure if we need to check for output size != 1, since we
// are currently marking all size-1 dimension as broadcast in codegen.
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

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

Yes you should. We mark it as broadcast, but something is only "truly" a broadcast when it gets broadcasted. Broadcast op is almost like a "maybe broadcast".

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

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

Doesn't have to be in this PR, can leave this TODO for later.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Thanks, I'd like to keep it TODO for now.

I'm only worried that it would still trigger propagation failure even if it's not a real broadcast.

@jjsjann123
Copy link
Copy Markdown
Collaborator Author

Merging this one as-is, please comment if I miss-read any review, I can accommodate them in later PR.

@jjsjann123 jjsjann123 merged commit 5e06675 into 20_7_6_devel Aug 13, 2020
@csarofeen csarofeen deleted the graph_partition_with_broadcast_logic branch June 9, 2021 13:38
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.

[1.0 Requirement] Partitioning logic update

2 participants