quil-lang / qvm Goto Github PK
View Code? Open in Web Editor NEWThe high-performance and featureful Quil simulator.
License: Other
The high-performance and featureful Quil simulator.
License: Other
Due to a typo in the option definition.
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
.)
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.
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?
naan:qvm robert$ echo 'H 0' | ./qvm
******************************
* Welcome to the Rigetti QVM *
******************************
Copyright (c) 2016-2019 Rigetti Computing.
(Configured with 8192 MiB of workspace and 8 workers.)
<135>1 2019-04-26T17:12:11Z naan.local qvm 85234 - - Selected simulation method: pure-state
<135>1 2019-04-26T17:12:11Z naan.local qvm 85234 - - Starting server on port 5000.
$ echo 'H 0' | ./qvm -e
******************************
* Welcome to the Rigetti QVM *
******************************
Copyright (c) 2016-2019 Rigetti Computing.
(Configured with 8192 MiB of workspace and 8 workers.)
<135>1 2019-04-26T17:13:19Z naan.local qvm 85236 - - Selected simulation method: pure-state
<132>1 2019-04-26T17:13:19Z naan.local qvm 85236 - - --execute/-e is deprecated. Elide this option for equivalent behavior.
<135>1 2019-04-26T17:13:19Z naan.local qvm 85236 - - Warning: Ignoring execute option: T
<135>1 2019-04-26T17:13:19Z naan.local qvm 85236 - - Starting server on port 5000.
wavefunction-qubits
returns the number of qubits in a wavefunction. But, this interface is not use consistently. Is this an oversight, or intentional ?
Examples:
but not here
https://github.com/rigetti/qvm/blob/74dd8f39907e6fc99a1beb392d096f8f52730ae0/src/measurement.lisp#L32
quil-lang/quilc#237 introduces forked gates to Quil. We need to be able to simulate them too. (CC @ecpeterson)
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.
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.
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
.
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.
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
.
An error in the wild, someone echo
ing instead of cat
ing, 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.
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.
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.
Write a benchmark that does a simple scan of all parameters for a QAOA computation.
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 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.
$ ./qvm --benchmark --benchmark-type qft
******************************
* Welcome to the Rigetti QVM *
******************************
Copyright (c) 2016-2019 Rigetti Computing.
(Configured with 8192 MiB of workspace and 8 workers.)
<135>1 2019-04-26T17:14:15Z naan.local qvm 85238 - - Selected simulation method: pure-state
! ! ! Condition raised: No restart CONTINUE is active.
<131>1 2019-04-26T17:14:16Z naan.local qvm 85238 - - Error encountered, quitting.
quilc reads stdin by default, but qvm-app requires an explicit cmd argument "-e"
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)
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".
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.
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.
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)
?
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.
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
.
makes it more unixy
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.
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)))
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:
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.
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.
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:
This was requested by the Slack community.
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.
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.
Fiasco now supports skipping tests. Use that where appropriate (e.g. skip shared memory tests on windows).
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.
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.
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?
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.
This may go into the court of CL-SYSLOG, but calling format-log
from multiple threads causes a segfault. Locking it makes it work.
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:
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.
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 BIT
s of memory.
Host, port, proxy, etc.
Right now, DQVM requires that the number of nodes used be a power of two. Generalize to remove this requirement.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.