Update the vf2 call limit to scale with the size of the input graph #8246
Conversation
|
Thank you for opening a new pull request. Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient. While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone. One or more of the the following people are requested to review this:
|
There was a problem hiding this comment.
Thanks for starting this, I have a couple questions. I see the scaling factor you inserted into the VF2Layout pass, but it looks like the intent is to make the internal call limit solely a function of the subgraph size if not explicitly passed in. Were you planning to add any scaling based on the optimization level? Also I'm unclear on where the call_limit parameter is originating from now in this PR. It looks like you're removing the hard coding and passing it in via the pass manager config, but that doesn't actually seem to be added to the pass manager config class. So I'm curious at a high level what is the expected workflow here? What is the intended use of call_limit at the pass manager level used for with your change (if it's still used at all)? I think maybe it would be helpful to have in the commit message an outline of how this change and the expected workflow with it (this would also be good as part of a release note documenting the change).
To answer your question about call_limit and vf2_call_limit. They're the same thing, vf2_call_limit is just an outer variable which also gets passed to the routing stage generator function and it defaults to None so that we avoid running VF2PostLayout if a manual layout method was specified. This was done to deduplicate the call_limit handling between the pre and post vf2 layout functions (originally both just had the same hard coded value).
| @@ -81,6 +81,7 @@ def level_1_pass_manager(pass_manager_config: PassManagerConfig) -> StagedPassMa | |||
| unitary_synthesis_plugin_config = pass_manager_config.unitary_synthesis_plugin_config | |||
| timing_constraints = pass_manager_config.timing_constraints or TimingConstraints() | |||
| target = pass_manager_config.target | |||
| call_limit = pass_manager_config.call_limit | |||
There was a problem hiding this comment.
Are you adding this to the passmanager config somewhere? I don't see that change anywhere
Set `call_limit` to be the maximum of either the retworkx 0.10.2 call limits or a scaled factor of the exponential call limit calculated in `./qiskit/transpiler/passes/layout/vf2_layout.py`. The scaling factor grows with the optimization level: 0.25 for level 1, 0.50 for level 2, and 0.75 for level 3.
Added scaling in 7950406.
Honestly, I wasn't sure how to get
I imagine that most users will not set
OK. I set |
|
Closing this PR as it seems more research is needed before proceeding, we can always open it again at a later date when more information is available |
Summary
Update
vf2algorithm call limit per #7705.Details and comments
The code for the layout passes has been updated recently, and I am not entirely sure what the difference between
call_limitandvf2_call_limitis intended to be.I also do not know if
self.call_limitis the preferred way to pass thecall_limitparameter.