QVM performance cliff at a specific number of shots

[caryan]

It is not super clear which part is to blame (it could just be the serialization/deserialization) but there is a surprising performance hit at a specific number of shots for a simple 1Q program

(base) cryan@cryan-Precision-5510 ~ $ qvm --version
1.5.0 [aacb70c]
(base) cryan@cryan-Precision-5510 ~ $ qvm -S
******************************
* Welcome to the Rigetti QVM *
******************************
Copyright (c) 2016-2019 Rigetti Computing.

This is a part of the Forest SDK. By using this program
you agree to the End User License Agreement (EULA) supplied
with this program. If you did not receive the EULA, please
contact <[email protected]>.

(Configured with 10240 MiB of workspace and 8 workers.)

<134>1 2019-03-26T00:07:34Z cryan-Precision-5510 qvm 4752 - - Selected simulation method: pure-state
<134>1 2019-03-26T00:07:34Z cryan-Precision-5510 qvm 4752 - - Starting server on port 5000.

import pyquil
print(pyquil.__version__)
2.5.2

from pyquil import Program, get_qc0
from pyquil.gates import *

qc = get_qc('1q-qvm')

NUM_SHOTS = 973
prog_a = Program()
ro = prog_a.declare('ro', 'BIT', 1)
prog_a += RX(np.pi/2, 0)
prog_a += MEASURE(0, ro[0])
prog_a.wrap_in_numshots_loop(NUM_SHOTS)
%timeit bitstrings = np.array(qc.run(prog_a))

6.15 ms ± 471 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

NUM_SHOTS = 974
prog_a = Program()
ro = prog_a.declare('ro', 'BIT', 1)
prog_a += RX(np.pi/2, 0)
prog_a += MEASURE(0, ro[0])
prog_a.wrap_in_numshots_loop(NUM_SHOTS)
%timeit bitstrings = np.array(qc.run(prog_a))

59.6 ms ± 1.16 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)

The QVM shows that "Finished in" goes from 2-3 ms to 9-10ms so a surprising jump but not largely responsible.

[stylewarning]

That is surprising and curious. (You're not secretly decoding some 4K video in the background are you? :))

[notmgsk]

Results for me, in same order

# NUM_SHOTS = 973
4.5 ms ± 17.2 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
# NUM_SHOTS = 974
4.62 ms ± 11.2 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

@caryan you still seeing this behaviour?