Always run vf2 scoring serially

[mtreinish]

Summary

The VF2Layout and VF2PostLayout passes' Rust scoring function has the option to use a parallel iterator for computing the score of a layout given a sufficiently large circuit (both in number of 2q interactions or qubits). Previously the scoring would be multithreaded if there were > 50 qubits or > 50 2q interactions in the circuit. However, as recent testing has shown in most cases the performance of doing this operation in parallel is much worse than serial execution. To address this issue, this commit just always uses the serial version. The parallel option is left in place for now just in case someone was manually calling the scoring function with the parallel option set to True.

Details and comments

[qiskit-bot]

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

• @Qiskit/terra-core

[mtreinish]

For comparison these are the performance results from this PR compared to main running in parallel:

I generated that using this script:

import time

from qiskit.transpiler.preset_passmanagers import common 
from qiskit.transpiler.passes import VF2PostLayout
from qiskit.transpiler.preset_passmanagers import plugin
from qiskit.transpiler.passmanager_config import PassManagerConfig
from qiskit.providers.fake_provider import FakeSherbrooke
from qiskit import QuantumCircuit


backend = FakeSherbrooke()
pm_config = PassManagerConfig.from_backend(backend, seed_transpiler=42)

pm = common.generate_unroll_3q(backend.target)
pm += plugin.PassManagerStagePluginManager().get_passmanager_stage("layout", "default", pm_config, optimization_level=3)

call_limit, max_trials = common.get_vf2_limits(optimization_level=3)
vf2_pass = VF2PostLayout(target=backend.target, call_limit=call_limit, max_trials=max_trials, seed=42, strict_direction=False)

times = []
for n in range(2, 127):
    qc = QuantumCircuit(n, n - 1)
    qc.x(n-1)
    qc.h(range(n))
    qc.cx(range(n-1), n-1)
    qc.h(range(n-1))
    qc.barrier()
    qc.measure(range(n-1), range(n-1))
    to_post_layout = pm.run(qc)
    start = time.perf_counter()
    vf2_pass(to_post_layout)
    stop = time.perf_counter()
    times.append(stop - start)
    print(stop - start)
print(times)

[coveralls]

Pull Request Test Coverage Report for Build 6643541599

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 13 unchanged lines in 3 files lost coverage.
• Overall coverage increased (+0.002%) to 86.915%

---

Files with Coverage Reduction	New Missed Lines	%
qiskit/extensions/quantum_initializer/squ.py	2	84.15%
crates/qasm2/src/lex.rs	5	91.92%
crates/accelerate/src/vf2_layout.rs	6	83.64%

Totals
Change from base Build 6642110371:	0.002%
Covered Lines:	73967
Relevant Lines:	85103

---

💛 - Coveralls

[kevinhartman]

This looks good. Technically changing the default behavior in vf2_utils would be a breaking change right? Though the impact is non-functional, and even still, going from parallel to single threaded wouldn't really have caller implications. Still might be good to have a release note.

[mtreinish]

Yeah, I'm not sure it's a breaking change, vf2_utils is not really part of our documented public API it's only really useful for the vf2 passes themselves. For the passes themselves it's just an internal implementation detail, I don't think the API contract for VF2Layout or VF2PostLayout ever explicitly stated that it ran in multiple threads. That being said I'll write a quick other section release note to document this just in case.

[mtreinish]

I added the release note in: a868032

[kevinhartman]

LGTM