Seed Luus Jaakola with left cost since we already know it. #1692
Conversation
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
added 3 commits
February 7, 2024 13:50
…orch#1690) Summary: EmbeddingOffloadScaleupProposer attempts to find an approximately optimal trade-off between using extra cache memory to reduce prefetch delay and the additional plan cost resulting from a more challenging bin-packing of larger shards. Currently a binary search is used under the assumption that the cost would consistently decrease in the evaluated region. However, investigation revealed that the cost region can be non-smooth and multi-modal, leading to poor results with the binary search. This diff implements the Luus Jaakola search procedure which is much more robust and capable of navigating 'rough terrain'. In a subsequent diff EmbeddingOffloadScaleupProposer will be updated to utilize this approach instead of the binary search. See https://en.wikipedia.org/wiki/Luus-Jaakola for detail. Reviewed By: henrylhtsang Differential Revision: D52686075
…torch#1691) Summary: Replace binary-search with Luus Jaakola. This works better at navigating the non-smooth planner cost surface when exploring cost vs cache memory. Reviewed By: henrylhtsang Differential Revision: D53296719
Summary: In scaleup, we already know the cost of the left hand boundary (the plan using min-working set). It's possible the clamped random search might probe the left-hand margin again, which wastes a (cached) call to the partitioner, using up one of our precious iterations without learning anything new. Instead we inform Luus Jaakola search we already know the left margin cost, so in these cases we can choose a new probe point that hopefully discovers a better minimum. Reviewed By: henrylhtsang Differential Revision: D53297896
facebook-github-bot
added
the
CLA Signed
|
This pull request was exported from Phabricator. Differential Revision: D53297896 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary:
In scaleup, we already know the cost of the left hand boundary (the
plan using min-working set). It's possible the clamped random search
might probe the left-hand margin again, which wastes a (cached) call
to the partitioner, using up one of our precious iterations without
learning anything new. Instead we inform Luus Jaakola search we
already know the left margin cost, so in these cases we can choose a
new probe point that hopefully discovers a better minimum.
Reviewed By: henrylhtsang
Differential Revision: D53297896