-
Notifications
You must be signed in to change notification settings - Fork 749
Assemble circuits and transpiler peakmem benchmarks #641
Assemble circuits and transpiler peakmem benchmarks #641
Conversation
4a70a89
to
8e65e26
Compare
8e65e26
to
b14d240
Compare
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.
LGTM, a couple inline questions but nothing blocking
|
||
|
||
class AssemblerBenchmarks: | ||
params = ([1, 2, 5, 8], |
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.
Do we want to expand the number of qubits here at all. Just to get a feel for how this scales as we approach the largest sizes?
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.
Yes and no. There are performance issues in assemble
for larger n_qubits
(e.g. we do some List.index
s that should be dictionary look ups) but right now, far and away, performance scales with the number of gates. I limited n_qubits
in the interest of keeping the benchmark runtime reasonable, but we can always expand it.
(As an aside, since we generate random circuits by depth and not by gate count, increasing n_qubits
does dramatically increase the benchmark runtime but only because the test circuits contain more gates, so there's not a lot of interesting information there, at least right now. Maybe we should update random_circuit
to accept either depth
or gate_count
.)
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.
That's a good point, I figured it was for run time. Yeah most of the time is spent looping over the instructions in experiments.
If we wanted to add a gate_count parameter it'd be simple to do (my first implementation of random circuit which we didn't use in terra actually did it this way). We should do this before we adopt any benchmarks with it though because we'd have to regenerate any data.
Co-Authored-By: Matthew Treinish <mtreinish@kortar.org>
Ci Passed, not that we actually run benchmarks in CI (still waiting on the new asv release with the |
…tapackage#641) Adds a peakmem tracking for transpiler_level benchmarks, and a benchmark for assemble_circuits. * Add peakmem versions of transpiler level benchmarks. * Add assemble_circuit benchmark. * Import assemble from qiskit.compile.
…tapackage#641) Adds a peakmem tracking for transpiler_level benchmarks, and a benchmark for assemble_circuits. * Add peakmem versions of transpiler level benchmarks. * Add assemble_circuit benchmark. * Import assemble from qiskit.compile.
Adds a peakmem tracking for transpiler_level benchmarks, and a benchmark for assemble_circuits.