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

[hannk] Add a prepare() method for ops and interp #6338

Merged
merged 5 commits into from
Oct 26, 2021

Conversation

steven-johnson
Copy link
Contributor

@steven-johnson steven-johnson commented Oct 20, 2021

This adds a new method to the Interpreter, and to all ops, which allows the interpreter (and each op) to do any one-time preparation for future executions. Previously this was lumped into either the Interpreter's ctor, or the Ops various other methods, but this has some nice advantages at minimal cost:
- Since the new prepare() returns an error value, it allows the Interpreter to do sanity checking at startup and return an error to the caller (rather than simply crashing); this makes using it in some runtime environments less painful.
- Ops can use this to prep and cache information for multiple subsequent runs; initially, Conv and DepthwiseConv use this to calculate and cache the alignment requirements they need later on. This is unlikely to be a huge performance hit, but it is likely nonzero, and As an added bonus, this means that e.g. the map_bounds() method is no longer susceptible to runtime failures from Halide bounds queries.

This adds a new method to the Interpreter, and to all ops, which allows the interpreter (and each op) to do any one-time preparation for future executions. Previously this was lumped into either the Interpreter's ctor, or the Ops various other methods, but this has some nice advantages at minimal cost:
- Since the new prepare() returns an error value, it allows the Interpreter to do sanity checking at startup and return an error to the caller (rather than simply crashing); this makes using it in some runtime environments less painful.
- Ops can use this to prep and cache information for multiple subsequent runs; initially, Conv and DepthwiseConv use this to calculate and cache the alignment requirements they need later on. This is unlikely to be a huge performance hit, but it is likely nonzero, and As an added bonus, this means that e.g. the map_bounds() method is no longer susceptible to runtime failures from Halide bounds queries.
@steven-johnson steven-johnson merged commit 47fa87f into master Oct 26, 2021
@steven-johnson steven-johnson deleted the srj/hannk-alignments branch October 26, 2021 17:22
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.

2 participants