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

[Relay] add fatal #3911

Closed
wants to merge 2 commits into from
Closed

[Relay] add fatal #3911

wants to merge 2 commits into from

Conversation

MarisaKirisame
Copy link
Contributor

@slyubomirsky
Copy link
Contributor

Mostly looks good and it is good to have a more explicit solution to the problem of incomplete matches. A couple of issues besides the questions I've labeled:

  • Test cases for hashing and alpha-equal would be good too (they're dull but if anything goes wrong with those, it could be a problem in many areas)
  • We'd have to update various interpreters to handle fatal nodes and have test cases for those

@slyubomirsky
Copy link
Contributor

Thanks for addressing the feedback. I think these changes are good (pending linting fixes)

@MarisaKirisame
Copy link
Contributor Author

@slyubomirsky can you approve explicitly?

TVM_REGISTER_API("relay._make.Fatal")
.set_body_typed(FatalNode::make);

std::string NoMatchMsg() {
Copy link
Member

Choose a reason for hiding this comment

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

I feel we can just use constexpr or an enum to define some common error messages in both C++ and python. Not necessary to define such an API.
otherwise lgtm

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have to copy the string twice if it is a constant though. I feel like api is cleaner and not cumbersome to use too.

@MarisaKirisame
Copy link
Contributor Author

Hi ppl, I add pytest.ini and updated tests/lint/check_file_type.py, is it ok?

@slyubomirsky
Copy link
Contributor

Should there be an AST header on the pytest.ini? The linter is complaining about it, but should the .ini file be an exception?

Copy link
Contributor

@wweic wweic left a comment

Choose a reason for hiding this comment

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

lgtm.

@@ -513,6 +513,32 @@ class RefWriteNode : public ExprNode {

RELAY_DEFINE_NODE_REF(RefWrite, RefWriteNode, Expr);

/*! \brief A fatal error has occured. Stop all execution and report with a message. */
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
/*! \brief A fatal error has occured. Stop all execution and report with a message. */
/*! \brief A fatal error has occurred. Stop all execution and report with a message. */

x = Var("x", l(a))
y = Var("y")
z = Var("z")
nil_case = Clause(PatternConstructor(nil, []), Fatal("cannot pass nil into head"))
Copy link
Contributor

Choose a reason for hiding this comment

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

this line is not used.

@MarisaKirisame
Copy link
Contributor Author

@wweic @icemelon9 I had addressed the review comment, can you guys give another round of review or approve?

Copy link
Contributor

@wweic wweic left a comment

Choose a reason for hiding this comment

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

lgtm. could you fix the CI error?

@broune
Copy link
Contributor

broune commented Oct 19, 2019

I was actually just now looking at support for Asserts, so this will be useful to me (Thanks to Wei for pointing me to this PR). I had been wondering what the TVM Relay policy is on side effects? I see that there is already Ref, but I didn't find the policy on it for Relay, and I wonder what it is. Side effects do change how a lot of optimizations can be done.

(Turns out, if you Google for "TVM side effects", the result is an official message "FDA Warns Public of TVM Side Effects", so I guess there's that, too.)

@wweic
Copy link
Contributor

wweic commented Oct 19, 2019

@broune Thanks for bringing it up! cc @tqchen @jroesch @zhiics @icemelon9

Regarding this PR, @MarisaKirisame please rebase so I can approve.

@MarisaKirisame
Copy link
Contributor Author

@broune relay is a purposefully side-effect language - it has side effect, and it is the key ingridient for our automatic differentiation algorithm.
However, most pass assume the none existence of side effect, because it turn out having ocaml style Ref is very, very hard to reason about! I always planned to add an abstracting abstract machine to relay to deal with them, but it is hard and I have no time. So, they are only half-supported, use at your own risk.

lint

lint

lint

do

make completeness check an error

lint

drop changes

address review comment

lint

address review

add asf header

fix
@tqchen
Copy link
Member

tqchen commented Oct 21, 2019

I think it would be good to introduce a thread discussing side effect. My feeling is that we want to keep most of the code functional(which makes them easy to optimize) and only introduce side effect when necessary(e.g. update rules). Side effect was not necessary for first-order AD, and for higher order ADs, we will need to find out a way to reduce as many as possible, and has not yet becomes concern.

In a gist, a large component of optimizations could be focusing on optimizing side-effect free programs. @broune seems to have a lot of thoughts for relaxing the side effect semantics. I think that makes sense especially for asserts, mainly because we only want to receive errors in boundaries of functions(which could be an entire graph) and I think we could reorder things in these cases.

@jroesch
Copy link
Member

jroesch commented Oct 21, 2019

@broune maybe we can have a longer form discussion and draft an RFC together? the current policy is if you don't use ref, the program should be side-effect free. I believe this may be violated by a few ops but my goal is to avoid side effects, and make it easy to do side-effect free analysis for many use cases.

@broune
Copy link
Contributor

broune commented Oct 22, 2019

I'm happy to discuss further in whichever venue. (No side effects is ideal for optimization but hard to get 100%. E.g. with dynamic shapes, most ops can have shape errors at runtime, making them side effecting unless somehow the error becomes an output in the dataflow graph. A random number generator library like TVM's tvm.contrib.random has random numbers that are different each time you call the op, which is stateful and a side effect.)

@MarisaKirisame
Copy link
Contributor Author

MarisaKirisame commented Oct 22, 2019

@tqchen that's the point of the PE pass.
However, side effect appear more then in AD.
Dropout introduce randomness, which is a form of side effect - referential transparency is broken. If you copy code that has dropout, they will return different answer when run.
Batchnorm also introduce side effect, as they maintain some global variable.
My take is that, people, sooner or later, has to embrace side effect, for training is full of them.
While that is painful, we can build analysis framework using abstract interpretation to still allow ppl to write basic, first order algorithm (the abstract interpreter will take the responsibility of dealing with control flow, closure, side effect).

on another note, can somebody get this merged? this had been sitting for a long time.

@wweic
Copy link
Contributor

wweic commented Oct 28, 2019

@jroesch @zhiics @icemelon9 @tqchen ping.

Copy link
Member

@zhiics zhiics left a comment

Choose a reason for hiding this comment

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

LGTM. @jroesch @icemelon9 please take another look as well.

@tqchen tqchen assigned icemelon and unassigned icemelon Oct 30, 2019
@tqchen
Copy link
Member

tqchen commented Mar 30, 2020

close for now due to inactive status, feel free to bring another PR to the master

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

Successfully merging this pull request may close these issues.

8 participants