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

Make outputsize understand multiple inputs #1486

Merged
merged 12 commits into from
Jan 30, 2021
Merged

Conversation

mcabbott
Copy link
Member

Closes #1466

darsnack
darsnack previously approved these changes Jan 28, 2021
Copy link
Member

@darsnack darsnack left a comment

Choose a reason for hiding this comment

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

No complaints from me. I like the more informative error message. We'll have to make sure it stays in sync with the actual implementation of Chain, but I think it is worth it.

@mcabbott
Copy link
Member Author

Great. As long as it still seems fast enough for your applications, that's one possible concern. It is only the outermost Chain, with no attempt to recurse into try/catch-ing sub-sub-layers.

@darsnack
Copy link
Member

Good point, I'll double check the speed like we did on the original PR. But I think for its use case, a minor slowdown is fine for convenient errors. It doesn't need to be super fast, just faster than evaluating ResNet-101 (which this should be).

Copy link
Member

@darsnack darsnack left a comment

Choose a reason for hiding this comment

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

Sorry for the delay. Here are the benchmarks on a large model:

julia> m = densenet_121();

# this PR
julia> @benchmark Flux.outputsize($m, (256, 256, 3, 50))
BenchmarkTools.Trial:
  memory estimate:  201.89 KiB
  allocs estimate:  4546
  --------------
  minimum time:     402.313 ms (0.00% GC)
  median time:      410.185 ms (0.00% GC)
  mean time:        423.873 ms (0.00% GC)
  maximum time:     480.239 ms (0.00% GC)
  --------------
  samples:          12
  evals/sample:     1

# Flux#master
julia> @benchmark Flux.outputsize($m, (256, 256, 3, 50))
BenchmarkTools.Trial:
  memory estimate:  278.48 KiB
  allocs estimate:  6634
  --------------
  minimum time:     416.605 ms (0.00% GC)
  median time:      417.849 ms (0.00% GC)
  mean time:        419.333 ms (0.00% GC)
  maximum time:     431.575 ms (0.00% GC)
  --------------
  samples:          12
  evals/sample:     1

I think based on that, it's good to merge.

@darsnack
Copy link
Member

Think we still need someone with merge rights like @CarloLucibello

@mcabbott
Copy link
Member Author

Excellent, thanks for checking.

I'm not super-sure how rights work, or whether merging is blocked to anyone not called Bors?

@mcabbott
Copy link
Member Author

bors r+

@darsnack
Copy link
Member

Yeah I had the same confusion. All I know is Github says I don't have merge rights, but I don't know if I'm allowed to call bors or not.

@CarloLucibello
Copy link
Member

I now see "1 approving review by reviewers with write access", so Kyle's rights have been fixed and hopefully he should also be able to call bors. want to try calling bors yourself @mcabbott ?

@CarloLucibello
Copy link
Member

there you go

@darsnack
Copy link
Member

Thanks Carlo!

@CarloLucibello
Copy link
Member

yeah merging is blocked also for me here, can go only through bors

@darsnack
Copy link
Member

darsnack commented Jan 30, 2021

And my reading of ColPrac says that since Michael has write access only he is allowed to call bors after approval from someone else? (since he is the PR author)

@CarloLucibello
Copy link
Member

And my reading of ColPrac says that since Michael has write access only he is allowed to call bors after approval from someone else? (since he is the PR author)

yes, and this is enforced by current github's settings. Those settings are actually stricter than ColPrac since for colprac also an approval from someone without write access is enough

@mcabbott
Copy link
Member Author

OK, great. The direct merge button is still disabled for me, so I guess the enforcement is that Bors would not have listened to me, before the approval?

@CarloLucibello
Copy link
Member

OK, great. The direct merge button is still disabled for me, so I guess the enforcement is that Bors would not have listened to me, before the approval?

that or it does its run then fails to merge, can't remember which one

@bors
Copy link
Contributor

bors bot commented Jan 30, 2021

Build succeeded:

@bors bors bot merged commit dd5d110 into FluxML:master Jan 30, 2021
@mcabbott mcabbott deleted the outsize branch January 30, 2021 16:32
@mcabbott
Copy link
Member Author

If I'm reading the rules correctly, I may also merge PRs by other people, without another member's approval?

Such as #1009, which just celebrated its first birthday...

@CarloLucibello
Copy link
Member

yes. approve then call bors

@mcabbott
Copy link
Member Author

Ok, I tried. It says I need to be made a reviewer?

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.

Better handling for layers with multiple inputs w/ outputsize
3 participants