Skip to content
This repository has been archived by the owner on Nov 17, 2023. It is now read-only.

Refactor AGInfo and Imperative #14836

Closed
wants to merge 153 commits into from
Closed

Conversation

larroy
Copy link
Contributor

@larroy larroy commented Apr 29, 2019

Description

This refactor improves the code in the backward pass. Breaks a long function into smaller functions with more semantic variables that indicate what's happening and the intention. This makes the code hopefully bit easier to maintain.

Checklist

Essentials

Please feel free to remove inapplicable items for your PR.

  • The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
  • Changes are complete (i.e. I finished coding on this PR)
  • All changes have test coverage:
  • Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
  • Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
  • Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
  • Code is well-documented:
  • For user-facing API changes, API doc string has been updated.
  • For new C++ functions in header files, their functionalities and arguments are documented.
  • For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
  • Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
  • To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

  • Feature1, tests, (and when applicable, API doc)
  • Feature2, tests, (and when applicable, API doc)

Comments

  • If this change is a backward incompatible change, why must this change be made.
  • Interesting edge cases to note here

Copy link
Contributor Author

@larroy larroy left a comment

Choose a reason for hiding this comment

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

Is the submodule update required for this refactor? If not, I'd prefer if we don't update it as part of this PR.

Yes it's required.

@marcoabreu
Copy link
Contributor

Could you link the corresponding PR on the submodule please?

@marcoabreu marcoabreu added the pr-work-in-progress PR is still work in progress label Jul 18, 2019
@larroy
Copy link
Contributor Author

larroy commented Jul 18, 2019

apache/tvm#3017

@larroy
Copy link
Contributor Author

larroy commented Jul 18, 2019

#14095

@larroy
Copy link
Contributor Author

larroy commented Jul 18, 2019

apache/tvm#2576

@marcoabreu
Copy link
Contributor

Okay that looks reasonable, thanks :)

@larroy
Copy link
Contributor Author

larroy commented Jul 25, 2019

@marcoabreu @szha @apeforest @anirudhacharya can you guys approve if you don't have any more comments? Thanks.

@larroy
Copy link
Contributor Author

larroy commented Aug 5, 2019

@mxnet-label-bot add [pr-awaiting-review]

@marcoabreu marcoabreu added the pr-awaiting-review PR is waiting for code review label Aug 5, 2019
@larroy
Copy link
Contributor Author

larroy commented Aug 5, 2019

@mxnet-label-bot remove [pr-work-in-progress]

@marcoabreu marcoabreu removed the pr-work-in-progress PR is still work in progress label Aug 5, 2019
@larroy
Copy link
Contributor Author

larroy commented Aug 5, 2019

@mxnet-label-bot remove [pr-awaiting-response]

@marcoabreu marcoabreu removed the pr-awaiting-response PR is reviewed and waiting for contributor to respond label Aug 5, 2019
@eric-haibin-lin
Copy link
Member

LGTM

ref_count[eid] = 1;
}

// Assign context
auto vctx = PlaceDevice(idx);
auto vctx = PlaceDevice(indexed_graph);

// Infer shape type
{
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we create a function to infershape here, instead of using braces.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We could. Do you think we could leave that to an additional refactor? It's an incremental process as this code might have to be addressed for thread safety soon.

Copy link
Contributor

Choose a reason for hiding this comment

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

Since this work itself is a refactoring, would it be better to perform a complete one?

xs.reserve(variables.size());
x_grads.reserve(variables.size());
x_reqs.reserve(variables.size());
struct Imperative::GradientVariableNodes {
Copy link
Contributor

Choose a reason for hiding this comment

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

The efficiency of AOS vs SOA does not apply here as you only perform adding element and no ALU related ops in the loop.

On the other hand, using a struct of vectors seems only move the original code to a struct, could we improve the readability during this refactoring?

@larroy
Copy link
Contributor Author

larroy commented Sep 8, 2019

I don't think the code review flow in this PR is productive or encouraging and I have spent already too much time on this. Closing.

@larroy larroy closed this Sep 8, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Backend Issues related to the backend of MXNet pr-awaiting-review PR is waiting for code review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants