Fix Sabre extended set population order

[kevinhartman]

Summary

When building the extended set, the current traversal order uses a BFS of all nodes as they become unblocked. This means that the order in which we encounter 2Q operations isn't necessarily the ones closest to inclusion in the front layer first. Since we limit the size of the extended set, operations that are closer to the front layer might not actually be included.

To fix this, we change the traversal order to visit non-2Q nodes (namely, 1Q gates and control flow ops) as soon as they're unblocked. Otherwise, we do the original BFS. This way, we get a BFS specifically of 2Q nodes as they become unblocked.

Details and comments

Here's an example of the traversal orders before and after this PR for a 4 qubit circuit with a run of 1Q H gates, where the extended set is limited to size 4.

The magenta arrows show the traversal orders, and the numbers (1., 2., 3., 4.) denote the nodes that make up the extended set after traversal. Notice that the extended set on main doesn't contain the ECR gate that happens on q0 and q1, even though it is closer to being pulled into the front layer than the latter 2 ECR gates on q2 and q3.

[qiskit-bot]

One or more of the the following people are requested to review this:

• @Eric-Arellano
• @Qiskit/terra-core
• @kevinhartman
• @mtreinish

[coveralls]

Pull Request Test Coverage Report for Build 5883464567

• 17 of 17 (100.0%) changed or added relevant lines in 1 file are covered.
• 5 unchanged lines in 2 files lost coverage.
• Overall coverage increased (+0.02%) to 87.276%

---

Files with Coverage Reduction	New Missed Lines	%
crates/qasm2/src/expr.rs	1	93.76%
crates/qasm2/src/lex.rs	4	90.63%

Totals
Change from base Build 5883117042:	0.02%
Covered Lines:	74357
Relevant Lines:	85198

---

💛 - Coveralls

[jakelishman]

The logic behind doing this looks sensible to me - it was always easier to write the BFS traversal in the order I did because it's append-only, but maintaining a separate vector for eager iteration looks like a good choice.

It might be worth running the large-scale QFT/QV benchmarks from the asv suite to see how runtime performance changes here, if at all.

[coveralls]

Pull Request Test Coverage Report for Build 7024159580

• 20 of 20 (100.0%) changed or added relevant lines in 1 file are covered.
• 17 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.01%) to 87.244%

---

Files with Coverage Reduction	New Missed Lines	%
crates/qasm2/src/lex.rs	5	92.17%
crates/qasm2/src/parse.rs	12	97.13%

Totals
Change from base Build 7023941179:	-0.01%
Covered Lines:	60788
Relevant Lines:	69676

---

💛 - Coveralls

[kevinhartman]

@jakelishman:

It might be worth running the large-scale QFT/QV benchmarks from the asv suite to see how runtime performance changes here, if at all.

There did not appear to be any significant changes when I ran the transpilation benchmarks 🙂.

asv continuous -E virtualenv-py3.8 --split --no-only-change upstream/main wt-terra-sabre-ext-set-order --bench "Level.*time" --bench "transpil"
asv compare --only-changed upstream/main wt-terra-sabre-ext-set-order

Change	Before [89642bd] <wt-terra-sabre-ext-set-order~2>	After [1ab85c4]	Ratio	Benchmark (Parameter)
-	20.5±2ms	17.1±0.1ms	0.84	qft.QftTranspileBench.time_ibmq_backend_transpile(1) [Kevins-MacBook-Pro.local/virtualenv-py3.8]
-	126±9ms	108±1ms	0.86	qft.QftTranspileBench.time_ibmq_backend_transpile(13) [Kevins-MacBook-Pro.local/virtualenv-py3.8]
-	2.30±0.1s	2.05±0.02s	0.89	queko.QUEKOTranspilerBench.time_transpile_bss(3, 'sabre') [Kevins-MacBook-Pro.local/virtualenv-py3.8]
-	278±20ms	228±1ms	0.82	transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_179(1, 'stochastic', 'sabre') [Kevins-MacBook-Pro.local/virtualenv-py3.8]
-	435±20ms	331±3ms	0.76	transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_179(3, 'sabre', 'noise_adaptive') [Kevins-MacBook-Pro.local/virtualenv-py3.8]
-	664±30ms	547±20ms	0.82	transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_179(3, 'stochastic', 'sabre') [Kevins-MacBook-Pro.local/virtualenv-py3.8]
-	263±10ms	213±20ms	0.81	transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_180(2, 'sabre', 'dense') [Kevins-MacBook-Pro.local/virtualenv-py3.8]
-	558±10ms	501±10ms	0.9	transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_180(2, 'stochastic', 'dense') [Kevins-MacBook-Pro.local/virtualenv-py3.8]
-	863±40ms	742±7ms	0.86	transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_cnt3_5_180(3, 'sabre', 'dense') [Kevins-MacBook-Pro.local/virtualenv-py3.8]
+	269±10ms	303±2ms	1.13	transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_qft_16(0, 'stochastic', 'sabre') [Kevins-MacBook-Pro.local/virtualenv-py3.8]
-	377±40ms	294±20ms	0.78	transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_qft_16(2, 'sabre', 'noise_adaptive') [Kevins-MacBook-Pro.local/virtualenv-py3.8]
-	1.54±0.4s	1.07±0.01s	0.69	transpiler_qualitative.TranspilerQualitativeBench.time_transpile_time_qft_16(3, 'sabre', 'dense') [Kevins-MacBook-Pro.local/virtualenv-py3.8]

[jakelishman]

Your copy in actually seems to suggest an improvement I think? I ran a different set of benchmarks and saw the expected no change:

jake@ninetales$ asv compare -s ibm/main kevinh/wt-terra-sabre-ext-set-order

Benchmarks that have stayed the same:

       before           after         ratio
     [50e81374]       [1ab85c42]
     <tmp-sabre^2>       <tmp-sabre~1>
          257±3ms          272±5ms     1.06  mapping_passes.PassBenchmarks.time_sabre_layout(14, 1024)
          427±2ms          443±7ms     1.04  mapping_passes.PassBenchmarks.time_sabre_layout(20, 1024)
       68.7±0.6ms         72.1±1ms     1.05  mapping_passes.PassBenchmarks.time_sabre_layout(5, 1024)
          133±1ms          134±1ms     1.00  mapping_passes.PassBenchmarks.time_sabre_swap(14, 1024)
          213±2ms          211±1ms     0.99  mapping_passes.PassBenchmarks.time_sabre_swap(20, 1024)
       41.2±0.6ms       40.4±0.6ms     0.98  mapping_passes.PassBenchmarks.time_sabre_swap(5, 1024)
          147±1ms        146±0.7ms     0.99  qft.LargeQFTMappingTimeBench.time_sabre_swap(115, 'decay')
          152±2ms        152±0.7ms     1.00  qft.LargeQFTMappingTimeBench.time_sabre_swap(115, 'lookahead')
       2.30±0.01s          2.31±0s     1.00  qft.LargeQFTMappingTimeBench.time_sabre_swap(409, 'decay')
          2.23±0s       2.27±0.01s     1.02  qft.LargeQFTMappingTimeBench.time_sabre_swap(409, 'lookahead')
       4.11±0.01s       4.07±0.01s     0.99  quantum_volume.LargeQuantumVolumeMappingTimeBench.time_sabre_swap(1081, 10, 'decay')
       2.54±0.02s       2.52±0.02s     1.00  quantum_volume.LargeQuantumVolumeMappingTimeBench.time_sabre_swap(1081, 10, 'lookahead')
              n/a              n/a      n/a  quantum_volume.LargeQuantumVolumeMappingTimeBench.time_sabre_swap(1081, 100, 'decay')
              n/a              n/a      n/a  quantum_volume.LargeQuantumVolumeMappingTimeBench.time_sabre_swap(1081, 100, 'lookahead')
       34.1±0.7ms       34.3±0.3ms     1.01  quantum_volume.LargeQuantumVolumeMappingTimeBench.time_sabre_swap(115, 10, 'decay')
       31.4±0.3ms       31.0±0.6ms     0.99  quantum_volume.LargeQuantumVolumeMappingTimeBench.time_sabre_swap(115, 10, 'lookahead')
          295±3ms          293±1ms     0.99  quantum_volume.LargeQuantumVolumeMappingTimeBench.time_sabre_swap(115, 100, 'decay')
          280±2ms          285±4ms     1.02  quantum_volume.LargeQuantumVolumeMappingTimeBench.time_sabre_swap(115, 100, 'lookahead')
          389±4ms          392±4ms     1.01  quantum_volume.LargeQuantumVolumeMappingTimeBench.time_sabre_swap(409, 10, 'decay')
          412±3ms          403±4ms     0.98  quantum_volume.LargeQuantumVolumeMappingTimeBench.time_sabre_swap(409, 10, 'lookahead')
              n/a              n/a      n/a  quantum_volume.LargeQuantumVolumeMappingTimeBench.time_sabre_swap(409, 100, 'decay')
              n/a              n/a      n/a  quantum_volume.LargeQuantumVolumeMappingTimeBench.time_sabre_swap(409, 100, 'lookahead')

Maybe it's random-seed effects we're seeing in yours more? Either way, this looks good to me.