quil-lang / qvm Goto Github PK

I get the following error when running make cleanall && make test.

I was concerned this might be related to my recent changes in cl-quil.tweedledum, so I ran a make clean in the quilc directory as well.

Unhandled UNBOUND-SLOT in thread #<SB-THREAD:THREAD "main thread" RUNNING
                                    {10005205B3}>:
  The slot CL-QUIL::DIMENSION is unbound in the object
  #<PERMUTATION-GATE {1005F86273}>.

Backtrace for: #<SB-THREAD:THREAD "main thread" RUNNING {10005205B3}>
0: (SB-DEBUG::DEBUGGER-DISABLED-HOOK #<UNBOUND-SLOT DIMENSION {1005F86643}> #<unused argument> :QUIT T)
1: (SB-DEBUG::RUN-HOOK SB-EXT:*INVOKE-DEBUGGER-HOOK* #<UNBOUND-SLOT DIMENSION {1005F86643}>)
2: (INVOKE-DEBUGGER #<UNBOUND-SLOT DIMENSION {1005F86643}>)
3: (ERROR #<UNBOUND-SLOT DIMENSION {1005F86643}>)
4: (SB-KERNEL:WITH-SIMPLE-CONDITION-RESTARTS ERROR NIL UNBOUND-SLOT :NAME CL-QUIL::DIMENSION :INSTANCE #<CL-QUIL:PERMUTATION-GATE {1005F86273}>)
5: ((:METHOD SLOT-UNBOUND (T T T)) #<unused argument> #<CL-QUIL:PERMUTATION-GATE {1005F86273}> CL-QUIL::DIMENSION) [fast-method]
6: ((LAMBDA (SB-KERNEL:INSTANCE) :IN SB-PCL::MAKE-OPTIMIZED-STD-READER-METHOD-FUNCTION) #<CL-QUIL:PERMUTATION-GATE {1005F86273}>)
7: ((:METHOD TRANSITION (PURE-STATE-QVM CL-QUIL:GATE-APPLICATION)) #<PURE-STATE-QVM {1005F20513}> #<CONTROLLED X 0 1>) [fast-method]
8: ((:METHOD RUN (PURE-STATE-QVM)) #<PURE-STATE-QVM {1005F20513}>) [fast-method]
9: ((FLET "EXECUTION-BODY-1" :IN TEST-CONTROLLED-X))
10: ((LABELS TEST-CONTROLLED-X :IN TEST-CONTROLLED-X))
11: ((LABELS FIASCO::RUN-TEST-BODY :IN FIASCO::RUN-TEST-BODY-IN-HANDLERS))
12: (FIASCO::CALL-WITH-TEST-HANDLERS #<CLOSURE (LAMBDA NIL :IN FIASCO::RUN-TEST-BODY-IN-HANDLERS) {1005EFD7AB}>)
13: (FIASCO::PRETTY-RUN-TEST #<test TEST-CONTROLLED-X> #<FUNCTION (LABELS TEST-CONTROLLED-X :IN TEST-CONTROLLED-X) {53F0DEAB}>)
14: ((LABELS #:BODY-SYM0 :IN TEST-CONTROLLED-X))
15: (TEST-CONTROLLED-X)
16: ((LABELS FIASCO-SUITES::QVM-TESTS :IN FIASCO-SUITES::QVM-TESTS))
17: ((LABELS FIASCO::RUN-TEST-BODY :IN FIASCO::RUN-TEST-BODY-IN-HANDLERS))

I am running the SDK QVM version 1.3.2 and ran into a very puzzling issue;

As far as I understood the QVM supports multiple workers/living on different threads. This is also what I find with qvm --benchmark, which by default runs a 26 qubit experiment. I'm running on a 12-core AMD 1920X which supports 24 threads, and during the benchmark I observe all CPU threads are active.

However, I am observing a strange deviation in run-time, in addition to CPU usage jumping from 100% to ~1500%, when I increase the qubit number from 18 to 19.

Minimal working example (I compiled the below via pyquil, and not directly in lisp, but below I show another example in command line QVM. ):

from pyquil.quil import Program
from pyquil.gates import H, CNOT, MEASURE
from pyquil.api import get_qc
import time


def test_multi_thread(N):
    prog = Program()
    ro = prog.declare('ro', memory_type='BIT', memory_size=N)

    prog += H(0)
    for j in range(N-1):
        prog += CNOT(j, j+1)

    for j in range(N):
        prog += MEASURE(j, ro[j])

    prog.wrap_in_numshots_loop(40)
    qc = get_qc(str(N)+'q-qvm')
    binary = qc.compile(prog)

    t = time.time()
    bitstrings = qc.run(binary)
    return time.time()-t


for n in [16, 17, 18, 19, 20, 21, 22]:
    print(str(n)+'-qubit experiment took ' + str(test_multi_thread(n))[:5] + ' seconds')

Then, the output for my particular machine results in:
16-qubit experiment took 5.752 seconds
17-qubit experiment took 12.02 seconds
18-qubit experiment took 26.18 seconds
19-qubit experiment took 8.229 seconds
20-qubit experiment took 14.66 seconds
21-qubit experiment took 29.66 seconds
22-qubit experiment took 53.15 seconds

Clearly, the 19-qubit experiment took shorter time than the 18 and even 17 qubit case. Based on the system monitor showing activity on a single vs multiple threads, therefore a hypothesis is multi-thread is enabled only past 18 qubits?

Also, I tested it by running the benchmark and it gives me this for 18 qubits:

qvm --benchmark 18
******************************
* 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 24 workers.)

<134>1 2019-02-20T21:12:36Z vincentelfving-linux qvm 21685 - - Selected simulation method: pure-state
<134>1 2019-02-20T21:12:36Z vincentelfving-linux qvm 21685 - - Computing baseline serial norm timing...
<134>1 2019-02-20T21:12:36Z vincentelfving-linux qvm 21685 - - Baseline serial norm timing: 0 ms
<134>1 2019-02-20T21:12:36Z vincentelfving-linux qvm 21685 - - Starting "bell" benchmark with 18 qubits...

Evaluation took:
  0.134 seconds of real time
  0.134324 seconds of total run time (0.134324 user, 0.000000 system)
  100.00% CPU

which shows 100.00% CPU for 18 qubits, while if I select a benchmark with 19 qubits:

qvm --benchmark 19
******************************
* 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 24 workers.)

<134>1 2019-02-20T21:12:31Z vincentelfving-linux qvm 21660 - - Selected simulation method: pure-state
<134>1 2019-02-20T21:12:31Z vincentelfving-linux qvm 21660 - - Computing baseline serial norm timing...
<134>1 2019-02-20T21:12:31Z vincentelfving-linux qvm 21660 - - Baseline serial norm timing: 1 ms
<134>1 2019-02-20T21:12:31Z vincentelfving-linux qvm 21660 - - Starting "bell" benchmark with 19 qubits...

Evaluation took:
  0.087 seconds of real time
  1.281765 seconds of total run time (1.079780 user, 0.201985 system)
  1473.56% CPU

it shows 1473.56% CPU... another indicator. Note that I find the same results with the option -w 24 added (which makes sense, it already defaulted to my system max of 24).

Is this behaviour reproduced on your side? If so, is it intentional?

This may go into the court of CL-SYSLOG, but calling format-log from multiple threads causes a segfault. Locking it makes it work.

Hi folks,

We're trying to get Forest working on a local machine, and we've run into a problem. Starting up either application in server mode would always return this:

C:\Program Files\Rigetti Computing\Forest SDK for Windows>qvm -S
! ! ! Condition raised: Condition USOCKET:TIMEOUT-ERROR was signalled.
<131>1 2019-05-09T20:47:07Z (hostname) qvm - - - Error encountered, quitting.

Both Linux and Windows installs result in the same behavior. I think I know what's going on, but I'm not familiar with Lisp so my diagnosis could be totally wrong here. Take it with a grain of salt.

After doing a little digging, I found the problem is caused by the latest-sdk-version call in qvm-app-version.lisp. The function uses drakma:http-request, which requires an explicit proxy setting. Since the proxy isn't set, the request times out. The timeout-error condition isn't caught by latest-sdk-version, only ns-host-not-found-error is, so this crashes the program.

We didn't find anything regarding proxy support in the Forest documentation, so we're assuming this is an open issue. At some point, we'd like for proxy support to be added so both tools can check for updates as intended. The lack of proxy support isn't really a blocker for us, though - the problem is how latest-sdk-version handles error conditions. It's breaking the entire program if the update check times out. In our opinion, it should probably just print a warning message if it can't contact the Rigetti server and let QVM and Quilc execute normally.

We're working around this by redirecting traffic aimed at downloads.rigetti.com to our local machine, which is running a webserver that just returns the JSON string that the actual server does, but this is obviously not ideal.

In main, we have a global var *program*. We should remove this.
(We should be able to just have a program local var in process-options.)

It Would Be Nice (TM) if the API to the QVM allowed access to the various "layers" of tensor factors in the execution. The QVM ought to understand (for noise/programmatic/etc) that

H 0
H 1

are logically in the same "layer".

For example, when I send the program H 1, the QVM rewrites 1 -> 0 as is expected behavior for using the least number of qubits possible, but for shared memory mode I actually want to apply a Hadamard gate to the qubit indexed 1, because my wavefunction persists from run to run. One can work around this by just applying the identity gate to all qubits at the beginning of the program, but maybe there is a better solution.

In DQVM src/main.lisp, there is a function resolve-safely. Similar functionality may already exist, in qvm or quilc. We should try to replace the validation that occurs within that function with an existing function, if there is one.

Due to a typo in the option definition.

quil-lang/quilc#237 introduces forked gates to Quil. We need to be able to simulate them too. (CC @ecpeterson)

Right now, MULTISHOT experiments under the parallelization limit only use a single core. We could use this as an opportunity to do multicore computations. The general flow would be:

1. Is the computation under the parallelization limit? If no, perform single-threaded.
2. Does the computation exceed the number of shots necessary to parallelize? If no, perform single-threaded.
3. Parallelize across threads, each modifying thread-local state, then combine state.

This was requested by the Slack community.

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.

It's possible we have superfluous syncs. There are the right number between master and worker nodes. However, it's still worth digging deeper. I think it may be possible to remove at least one pair of syncs. Also: there is a sync in reorganize-amplitudes, (and execute-instruction, calls reorganize-amplitudes). It would be better to keep all the syncs in the main loop for both worker and master.

The compiler routines all use CL-QUIL's resource abstraction, but the QVM uses a routine called qubits-used which separately implements (the qubit portion of) resource utilization tracking. Consider rewriting qubits-used to use the new resource tracking mechanisms, so that this information only has to get updated in one place.

Right now, DQVM requires that the number of nodes used be a power of two. Generalize to remove this requirement.

buildapp is super convenient, but it's an inconvenient step in the already inconvenient setup instructions. ASDF offers some portable ways to build, but we could also just have an SBCL-specific build script. (CC @rigettizach)

I get the following error when attempting to run make cleanall && make test-app.

$ make QUICKLISP_HOME=~/opt/rigetti-quicklisp test-app
sbcl --dynamic-space-size 2048 --noinform --non-interactive --no-userinit --no-sysinit --load /home/ma/opt/rigetti-quicklisp/setup.lisp --eval '(push (truename ".") asdf:*central-registry*)' --eval '(push :hunchentoot-no-ssl *features*)' --eval '(push :drakma-no-ssl *features*)' --eval "(push (truename \"../\") ql:*local-project-directories*)" \
         --eval '(ql:quickload :qvm-app-tests)' \
         --eval '(asdf:test-system :qvm-app)'
To load "qvm-app-tests":
  Load 1 ASDF system:
    qvm-app-tests
; Loading "qvm-app-tests"

...snip...

[package qvm-app-tests].....;
; caught ERROR:
;   READ error during COMPILE-FILE:
;
;     Package QUILC does not exist.
;
;       Line: 169, Column: 35, File-Position: 7260
;
;       Stream: #<SB-INT:FORM-TRACKING-STREAM for "file /home/ma/src/repos/rigetti/qvm/app/tests/suite.lisp" {1013E310A3}>
Unhandled UIOP/LISP-BUILD:COMPILE-FILE-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING
                                                          {10005205B3}>:
  COMPILE-FILE-ERROR while compiling #<CL-SOURCE-FILE "qvm-app-tests" "suite">

Backtrace for: #<SB-THREAD:THREAD "main thread" RUNNING {10005205B3}>
0: (SB-DEBUG::DEBUGGER-DISABLED-HOOK #<UIOP/LISP-BUILD:COMPILE-FILE-ERROR {1010E14563}> #<unused argument> :QUIT T)
1: (SB-DEBUG::RUN-HOOK *INVOKE-DEBUGGER-HOOK* #<UIOP/LISP-BUILD:COMPILE-FILE-ERROR {1010E14563}>)
2: (INVOKE-DEBUGGER #<UIOP/LISP-BUILD:COMPILE-FILE-ERROR {1010E14563}>)
3: (ERROR UIOP/LISP-BUILD:COMPILE-FILE-ERROR :CONTEXT-FORMAT "~/asdf-action::format-action/" :CONTEXT-ARGUMENTS ((#<ASDF/LISP-ACTION:COMPILE-OP > . #<ASDF/LISP-ACTION:CL-SOURCE-FILE "qvm-app-tests" "suite">)))

...snip...

This appears to be due to the following test, which was recently added to app/tests/suite.lisp:

(deftest test-server-startup-behaviour ()
  ;; Test that providing -p without -S does *not* start the server.
  (is (typep (with-input-from-string (*standard-input* "H 0")
               (quilc::%entry-point (list "quilc" "-p" "1000")))
             'hash-table))
  ;; TODO One day, some more checks that quilc behaves.
  )

Perhaps test-server-startup-behaviour is meant to test the option processing in qvm-app, not quilc? Otherwise, I guess quilc needs to be added as a dependency in qvm-app-tests.asd.

Right now the Lisp allocator is used for the wavefunction, and there's special case logic for shared memory. But it would be nice if a custom allocator could be provided. That would have the benefit of keeping the heap size small if, for example, a C-allocated vector could be used.

You can start the QVM with a persistent wavefunction using the shared memory command line arguments, but it would be nicer if this could happen on a request-by-request basis.

makes it more unixy

The variable *qubits-required-for-parallelization* is statically set to 19, which means that as soon as 19 qubits is reached in a computation, the computations will be parallelized.

This isn't ideal for all machines. Sometimes parallelization provides gains with values lower or higher than 19. The goal of this issue would be to search for that crossing point and optimize accordingly.

Problems that must be solved in order to solve this issue:

• How should the parallelization limit be calculated? (This is slightly non-trivial because many different things are parallelized in different contexts.)
• How can one invoke this calculation?
• Should the parallelization limit be stored on disk? Should it be provided as a command-line argument?

The functions check whether it is nil, so it should just default to nil

(defmethod measure ((qvm pure-state-qvm) q c)
  (check-type c (or null quil:memory-ref))
  (let* ((r (random 1.0d0))
         (excited-probability (qubit-probability qvm q))
         (cbit (if (<= r excited-probability)
                   1
                   0)))
    ;; Force the non-deterministic measurement.
    (force-measurement cbit q qvm excited-probability)

    ;; Store the classical bit if necessary.
    (unless (null c)
      (setf (dereference-mref qvm c) cbit))

    ;; Return the qvm.
    (values qvm cbit)))

Host, port, proxy, etc.

An error in the wild, someone echoing instead of cating, leads to the following:

$ echo foo.quil | qvm
******************************
* Welcome to the Rigetti QVM *
******************************
Copyright (c) 2016-2019 Rigetti Computing.

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

! ! ! Condition raised: Couldn't find match at position 3 within the lexer CL-QUIL::LINE-LEXER.

This is of course sensible in its behavior, but the error message is awful and should be more helpful.

DQVM src/common.lisp

docstring for +worker-count+
;;; The number of worker nodes. -> ;;; The number of worker nodes, which is the total number of nodes minus the master node.

with-total-readability
Print something with as many readability settings turned on. ->  Print something with many readability settings turned on. (or, as many... as possible)

cluster struct definition
*CLUSTER* should be **CLUSTER**

deserialize-cluster
Can we use clusterp rather than (typep c 'cluster)?

DQVM src/worker.lisp

first line: (declaim (optimize (speed 0) safety debug (compilation-speed 0))) probably warrants a comment

number-of-blocks
doctring should describe that these are the number of blocks across all workers, not per worker

iterate-worker-addresses
could use some good documentation, and we should see what else we can do to make it more readable

%main-worker
docstring is missing a period Main entry point to the worker This is only to be called by DQVM:%MAIN. -> Main entry point to the worker. This is only to be called by DQVM:%MAIN.
First comment ;; Wait for master to sync seems like it may be misplaced; I think we can delete.

Not sure how much overlap there is. linear-algebra.lisp defines things like make-matrix, matrix-multiply, and kronecker-multiply that are also available in MAGICL.

I have been working with @kylegulshen on a PR to forest-benchmarking that changes some unit tests which use the QVM. Strangely, there were some tests that failed when the full test suite was run, but not when run alone. There certainly could be other issues at play here, but on a whim I decided to change the QVM's random seed for one of the failing tests from 1 to 2 and suddenly things began working, which seemed alarming to me. I sense that there could be something deeper going on, so I just wanted to get this issue in writing and maybe spur some investigation.

Right now testing is failing because SSL was disabled by way of *features*. We should do a cache flush before the tests run.

@marcusps suggests that readout symmetrization is a useful way to improve error rates in readout by averaging over measurement of 0 and 1 states. The general procedure, as I understand it, is this:

Given an instruction like

MEASURE q c

uniformly randomly either do nothing, or transform it to

X q
MEASURE q c
NOT c

This will, over many shots, symmetrize the behavior of MEASURE, giving it asymptotically 50% chance of reading out 0 or 1.

It would not be wise to actually transform the Quil program, and this sort of thing ought to happen during compilation to actual quantum machine code. But for the purpose of simulating error, we can install this behavior into a transition method, probably on the noisy-qvm class where it's actually useful.

Fixing the profiler (see quilc) results in an error:

# snip

TEST-DENSITY-QVM-NOISY-MEASURE-ALL                                      [ OK ]
[Test output: aaaaaaaaa]
  TEST-QVM-GARBAGE-COLLECTION                                             [ OK ]
[Test output: awdawdawdawdawdawdawdawdawdawdawdawdawdawdawdawd]
  TEST-POSIX-SHARED-MEMORY-ALLOCATION/DEALLOCATION                        [ OK ]
[Test output: awdawdawdawdawdawdawdawdawdawdawdawdawdawdawdawd]
  TEST-SHARED-ARRAY-ALLOCATION/DEALLOCATION                               [ OK ]
[Test output: aaaaaaaWhile evaluating the form starting at line 36, column 0
  of #P"/Users/mark.skilbeck/hackery/qvm/coverage-report/coverage-report.lisp":

debugger invoked on a SIMPLE-ERROR in thread
#<THREAD "main thread" RUNNING {10005C05B3}>:
  Error in shm_open. Got return code -1: File exists

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [CONTINUE                             ] Skip the rest of the test
                                             TEST-SHARED-QVM-GARBAGE-COLLECTION
                                             and continue by returning (values)
  1: [RETEST                               ] Rerun the test
                                             TEST-SHARED-QVM-GARBAGE-COLLECTION
  2:                                         Skip the rest of the test
                                             FIASCO-SUITES::QVM-TESTS and
                                             continue by returning (values)
  3:                                         Rerun the test
                                             FIASCO-SUITES::QVM-TESTS
  4: [CONTINUE-WITHOUT-DEBUGGING           ] Turn off debugging for this test
                                             session and invoke the first
                                             CONTINUE restart
  5: [CONTINUE-WITHOUT-DEBUGGING-ERRORS    ] Do not stop at unexpected errors
                                             for the rest of this test session
                                             and continue by invoking the first
                                             CONTINUE restart
  6: [CONTINUE-WITHOUT-DEBUGGING-ASSERTIONS] Do not stop at failed assertions
                                             for the rest of this test session
                                             and continue by invoking the first
                                             CONTINUE restart
  7: [ABORT-TESTING                        ] Abort the entire test session
  8: [RETRY                                ] Retry
                                             #<TEST-OP > on #<SYSTEM "qvm-tests">.
  9: [ACCEPT                               ] Continue, treating
                                             #<TEST-OP > on #<SYSTEM "qvm-tests">
                                             as having been successful.
 10:                                         Retry ASDF operation.
 11: [CLEAR-CONFIGURATION-AND-RETRY        ] Retry ASDF operation after
                                             resetting the configuration.
 12:                                         Retry ASDF operation.
 13:                                         Retry ASDF operation after
                                             resetting the configuration.
 14: [RETRY                                ] Retry EVAL of current toplevel form.
 15:                                         Ignore error and continue loading file "/Users/mark.skilbeck/hackery/qvm/coverage-report/coverage-report.lisp".
 16: [ABORT                                ] Abort loading file "/Users/mark.skilbeck/hackery/qvm/coverage-report/coverage-report.lisp".
 17:                                         Ignore runtime option --load "coverage-report.lisp".
 18:                                         Skip rest of --eval and --load options.
 19:                                         Skip to toplevel READ/EVAL/PRINT loop.
 20: [EXIT                                 ] Exit SBCL (calling #'EXIT, killing the process).

(QVM::MAKE-POSIX-SHARED-MEMORY "TEST_C__7" 1073741840)
   source: (ERROR "Error in shm_open. Got return code ~D: ~A" FD
                  (%STRERROR %ERRNO))
0]

It only happens when profiling is enabled.

When using the wavefunction feature of the QVM (from pyQuil), sending the empty program returns a wavefunction array of length 1 (array([1.+0.j])), but sending the program I 0 returns a wavefunction array of length 2 (array([1.+0.j, 0.+0.j])). While I can certainly see the merit of these two returning different things, I'm not sure I would have expected the empty program to behave as such. Thoughts?

Write a benchmark that does a simple scan of all parameters for a QAOA computation.

Currently measurement on the density-qvm forces a particular measurement by way of a coin flip. This is correct behavior for the measurement instruction

MEASURE q c

However, it's not correct behavior for a bare measure-and-discard. This has the syntax

MEASURE q

and class quil:measure-discard. In this case, we should produce a mixed state on |0> and |1>. This can be accomplished by defining a transition method on density-qvm and quil:measure-discard.

qvm-app is an organically grown sloppy mess that's difficult to maintain, extend, etc. It wasn't on purpose, but it can be majorly improved.

A good start would be to improve options handling to not pass information through the plethora of globals.

wavefunction-qubits returns the number of qubits in a wavefunction. But, this interface is not use consistently. Is this an oversight, or intentional ?

https://github.com/rigetti/qvm/blob/74dd8f39907e6fc99a1beb392d096f8f52730ae0/src/wavefunction.lisp#L31-L34

Examples:

Used here
https://github.com/rigetti/qvm/blob/74dd8f39907e6fc99a1beb392d096f8f52730ae0/src/wavefunction.lisp#L41

but not here
https://github.com/rigetti/qvm/blob/74dd8f39907e6fc99a1beb392d096f8f52730ae0/src/measurement.lisp#L32

The test suite is taking a good while to finish. This could be improved by running only specific tests in both intepreted and compiled modes.

A few years ago, @vontell implemented gate fusion in quilc. Unfortunately, the code never finally landed in master, though the code is preserved.

The goal would be to learn from his approach to gate fusion, and implement it either in quilc or the qvm.

When PR #58 lands, LOAD-PROGRAM will mutate the program being loaded because patch-labels is being called. We should do work so that this mutation doens't cause unintended side-effects.

Fiasco now supports skipping tests. Use that where appropriate (e.g. skip shared memory tests on windows).

Quantum contextuality is known to be a key ingredient in producing quantum speedup—and, hence, in stymieing efficient classical simulation of quantum systems. As a sort of converse, Raussendorf et al. (https://arxiv.org/pdf/1905.05374.pdf) have a paper where they propose a scheme with the following traits:

1. Their method for simulation is 'efficient', presumably meaning that resource consumption scales polynomially with the number of qubits requested.
2. Their method for simulation subsumes the Gottesman stabilizer formalism.
3. The condition on Wigner functions is tightly coupled (though I am not clear on precisely how tightly) with non-contextuality, which is a gesture at the genericity of this method.

I haven't read this paper myself, but it seems like it could be reasonable fodder for a new QVM simulation mode. Someone ought to investigate.

I made some errors when trying to build qvm. After fixing the errors, the build still failed. It looks like deleting system-index.txt in the top-level directory (and also the same filename in both ~/ and in ~/quicklist/local-projects/) solved the error. It would be helpful to include this info in the build instructions.

quilc reads stdin by default, but qvm-app requires an explicit cmd argument "-e"

Right now, MULTISHOT or MULTISHOT-MEASURE gives bitstrings back. Often it's only necessary to look at a bunch of (uncorrelated) statistics. The QVM maybe should give a way of just giving histograms of |0>/|1> measurements back.

Now, of course this can be written in Quil directly with arithmetic instructions, but understandably, not all hardware easily supports this. If we implemented this as a special API case, we could restrict it to work on single BITs of memory.

Numerical stability has been "casually" thought about, but not very many intentional design decisions exist on its behalf. Numerical stability should be thought about, and there should be some documentation written about the findings.