-
Notifications
You must be signed in to change notification settings - Fork 18
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
Counter for number of improvements done #93
Merged
anhnamtran
merged 17 commits into
CozySynthesizer:master
from
anhnamtran:improvements-counter
Dec 26, 2018
Merged
Changes from all commits
Commits
Show all changes
17 commits
Select commit
Hold shift + click to select a range
9913dae
Added pymemcache as a dependency
anhnamtran 2ddb3c5
Added redis caching to cost model
anhnamtran 533a14a
Made generated cache files more readable
anhnamtran c9aeb7d
Added a counter ? It's not working lmao
anhnamtran be9f79a
Removed counter for improve
anhnamtran 558cf5b
Removed file writes that could slow things down
anhnamtran a42bf76
Preliminary improvements counter
anhnamtran b83f682
Added option to toggle cache
anhnamtran b8db01a
Removed cache from cost model
anhnamtran cbadfa7
Removed cache from cost model
anhnamtran 520a5b6
Merge branch 'improvements-counter' of github.com:anhnamtran/cozy int…
anhnamtran 3b1fc2f
Merge branch 'improvements-counter' of github.com:anhnamtran/cozy int…
anhnamtran 3483614
Merge branch 'improvements-counter' of github.com:anhnamtran/cozy int…
anhnamtran b73a71f
"Removed" default value for counter
anhnamtran 63447c0
Added check for whether or not the counter is None
anhnamtran ef66df2
Addressed comments:
anhnamtran ef339bc
Missed a variable
anhnamtran File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see a good reason to make this a global variable. Instead, could
high_level_interface.py
aggregate the total improvement count as improvements come in?I think that design would also support the use case in #99:
high_level_interface.py
could simply kill the worker processes when the number of improvements tips a threshold. This means the workers would need less internal logic, there is less global state and synchronization, and there would be one fewer parameters that need to pass between modules.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I realize this PR has already been merged, but it slipped under my radar. I think a simpler design here will make it much easier to build other features that use the improvement count in interesting ways.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason that this the counter is in
main.py
is because I wanted to have an easy way to print out the output of the counter after Cozy finishes running. Would putting it inhigh_level_interface.py
still be okay for that purpose (maybe with animport
)?Also if you look here, I've changed the implementation to use a
Queue
instead, so that I could also get the difference in time between eachimprove
call. Would putting it one level down inhigh_level_interface.py
add some difficulty to this as well?If the changes are insignificant/easy to do, then I can make the change and create a new merge request.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At the end of the day this is all a matter of taste and you should do what you feel is best. But just to clarify my thoughts:
If
main.py
needs the count, then it is cleaner to haveimprove_implementation
return it (along with the improved AST that it already returns). Python makes it easy to return multiple values; using "out-parameters" is a dated and convoluted pattern. (Er, ok fine, some parts of the Cozy codebase already do it. But I promise the reason is to avoid unnecessary allocations and that it actually makes a difference in those places!)The changes I would suggest are a little involved, but they feel like better design to me:
improve_count
parameter from everywhereimprove_implementation
should return a tuple of(ast, stats)
wherestats
is some documented structure that captures statistics about what happened during synthesis (like when different improvements happened)core.improve
can act the way it always hasimprove_implementation
can count the number of results it gets fromcore.improve
in this loop.core.improve
to yield, say,(result_type, result)
tuples, e.g.("improvement", x+1)
and("restart", some_new_example)
I like that design better since
multiprocessing
to callers of theimprove_implementation
functionmultiprocessing
's weird caveatsmultiprocessing
someday (Which I have always dreamed about. Can you imagine distributed Cozy running on a cluster?)core.improve
finds improvements in a loop forever, andhigh_level_interface.improve_implementation
managescore.improve
threads by aggregating their results and deciding when to terminate themimprove_implementation
: aggregate statistics about thecore.improve
threadsimprove_implementation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will look into this once the week starts!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Calvin-L I agree with what you proposed, but I am concerned about how to stop the
improve
loop if out-of-quota with this map-reduce like design, as what we are trying to achieve in #99.P.S. I just made a clarified graph of Cozy call-chain for reference here:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've opened up a new issue for this discussion: #102 so we can keep track of it. Thanks for making this happen @Calvin-L @anhnamtran