U.S. patent application number 17/220069 was filed with the patent office on 2022-03-17 for parcelled quantum resources.
This patent application is currently assigned to Rigetti & Co, Inc.. The applicant listed for this patent is Rigetti & Co, Inc.. Invention is credited to David Bryant, Anand Desai, Glenn Jones, Eric Christopher Peterson, Matthew J. Reagor, Chad Tyler Rigetti, Michael Rust, Robert Stanley Smith, Nikolas Anton Tezak.
Application Number | 20220084085 17/220069 |
Document ID | / |
Family ID | |
Filed Date | 2022-03-17 |
United States Patent
Application |
20220084085 |
Kind Code |
A1 |
Rigetti; Chad Tyler ; et
al. |
March 17, 2022 |
Parcelled Quantum Resources
Abstract
In a general aspect, methods and systems are described for
dynamically partitioning and virtualizing a monolithic
quantum-classical hybrid computing resource into multiple different
and independently-saleable, as a resource to a user, parcels. These
parcels may comprise configurations of qubits and qubit-qubit links
on one or more quantum processor units for use by users for running
computer programs.
Inventors: |
Rigetti; Chad Tyler; (Walnut
Creek, CA) ; Smith; Robert Stanley; (Emeryville,
CA) ; Reagor; Matthew J.; (Corte Madera, CA) ;
Rust; Michael; (Martinez, CA) ; Peterson; Eric
Christopher; (Miami, FL) ; Tezak; Nikolas Anton;
(Oakland, CA) ; Desai; Anand; (San Francisco,
CA) ; Jones; Glenn; (Berkeley, CA) ; Bryant;
David; (Oakland, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Rigetti & Co, Inc. |
Berkeley |
CA |
US |
|
|
Assignee: |
Rigetti & Co, Inc.
Berkeley
CA
|
Appl. No.: |
17/220069 |
Filed: |
April 1, 2021 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
PCT/US2019/056727 |
Oct 17, 2019 |
|
|
|
17220069 |
|
|
|
|
PCT/US2019/054568 |
Oct 3, 2019 |
|
|
|
PCT/US2019/056727 |
|
|
|
|
62746970 |
Oct 17, 2018 |
|
|
|
62746970 |
Oct 17, 2018 |
|
|
|
62740808 |
Oct 3, 2018 |
|
|
|
International
Class: |
G06Q 30/02 20060101
G06Q030/02; G06N 10/00 20060101 G06N010/00; G06Q 30/08 20060101
G06Q030/08 |
Claims
1-10. (canceled)
11. A method for calculating a price for use of a configuration of
qubits and qubit-qubit links on one or more quantum processor units
by a user for running a computer program, comprising: accessing a
first database by a computer processor unit to collect design
characteristics of the one or more quantum processor units,
including inferred characteristics pertaining to the expressiveness
of the one or more quantum processor units, wherein the inferred
characteristics include instruction availability; accessing a
second database by the computer processor unit to collect
measurements of physical characteristics of the one or more quantum
processor units; accessing a third database by the computer
processor unit to collect characteristics of a specific user's
request; and determining the price by the computer processor unit
using data collected from the first, second and third
databases.
12. The method of claim 11, further comprising accessing a fourth
database by the computer processor unit to collect data
characterizing a multiplicity of user requests, including user
requests by different users, and wherein the determining the price
uses data collected from the first, second, third and fourth
databases.
13. The method of claim 11, wherein the computer processor unit is
configured to calculate a price based at least in part on the
physical characteristics of the one or more quantum processor
units.
14. The method of claim 11, wherein the computer processor unit is
configured to determine a price based at least in part on user
demand for use of the one or more quantum processor units, and
preferably, the price is determined through a pricing auction
comprising one or more rounds.
15. (canceled)
16. The method of claim 14, wherein the computer processor unit is
configured to determine a price based at least in part on a
popularity of the specific configuration of qubits and qubit-qubit
links being requested by the user.
17. The method of claim 14, wherein a user requests to run the
program within a specified time frame, and wherein the computer
processor unit is configured to determine a price based at least in
part on the specified time frame.
18. The method of claim 14, wherein the first database includes
information on qubit count and qubit connectivity.
19. The method of claim 11, wherein the second database includes
one or more physical measurements of: gate fidelity, native gate
availability, qubit count, link count, link topology, readout
fidelity, qubit coherence time and qubit relaxation time.
20. The method of claim 12, wherein the fourth database includes
one or more of data characterizing system-wide strain and
historical usage patterns.
21. The method of claim 11, wherein the third database includes one
or more of an expected duration of use of one of the connected sets
of qubits and a requested calendar time for running the
program.
22-25.(canceled)
26. A computer system for calculating a price for use of a
configuration of qubits and qubit-qubit links on one or more
quantum processor units by a user for running a program,
comprising: a first database for storing design characteristics of
the one or more quantum processor units, including inferred
characteristics pertaining to the expressiveness of the device,
wherein the inferred characteristics include instruction
availability; a second database for storing measurements of
physical characteristics of the one or more quantum processor
units; a third database for storing characteristics of a specific
user's request; and a computer processor unit for determining the
price, wherein the computer processor unit is linked to the first,
second and third databases for accessing input data for the
determining.
27. The computer system of claim 26, further comprising a fourth
database for storing data characterizing a multiplicity of user
requests, including user requests by different users, and wherein
the computer processor unit is linked to the first, second, third
and fourth databases for accessing input data for the
determining.
28. The computer system of claim 26, wherein the computer processor
unit is configured to calculate a price based at least in part on
the physical characteristics of the one or more quantum processor
units.
29. The computer system of claim 26, wherein the computer processor
unit is configured to determine a price based at least in part on
user demand for use of the one or more quantum processor units, and
preferably, the price is determined through a pricing auction
comprising one or more rounds.
30. (canceled)
31. The computer system of claim 26, wherein the computer processor
unit is configured to determine a price based at least in part on
the popularity of the specific configuration of qubits and
qubit-qubit links being requested by the user.
32. The computer system of claim 26, wherein a user requests to run
the program within a specified time frame, and wherein the computer
processor unit is configured to determine a price based at least in
part on the specified time frame.
33. The computer system of claim 26, wherein the first database
includes information on qubit count and qubit connectivity.
34. The computer system of claim 26, wherein the second database
includes one or more physical measurements of: gate fidelity,
native gate availability, qubit count, link count, link topology,
readout fidelity, qubit coherence time and qubit relaxation
time.
35. The computer system of claim 27, wherein the fourth database
includes one or more of data characterizing system-wide strain and
historical usage patterns.
36. The computer system of claim 26, wherein the third database
includes one or more of an expected duration of use of one of the
connected sets of qubits and a requested calendar time for running
the program.
37. The computer system of claim 26, wherein one or more of the
first, second, and third databases are remote databases accessible
via network communication.
38. The computer system of claim 26, wherein one or more of the
first, second, and third databases are accessible from remote
agents via network communication.
39. The computer system of claim 26, wherein one or more of the
first, second, and third databases are local caches.
40. The computer system of claim 26, wherein two or more of the
first, second, and third databases are combined.
41. The method of claim 14, wherein the pricing auction comprises:
opening an auction and receiving price bids electronically
submitted by users, each price bid having an order with a user
desired qubit configuration, each order including a number of
qubits, a configuration of qubit connectivities, a lower bound on
qubit quality and one or more of a duration, a particular segment
of time and a minimum duration; rejecting a specific price bid of
the price bids unless the specific price bid satisfies a criteria,
the criteria including one or more of: a minimum number of qubits
and qubit-qubit links on one or more quantum processor units, a
start time of at least a fixed time in the future, and a maximum
duration; on satisfaction of one or more specific criteria, closing
the auction to any new price bids; activating an order filling
process, the order filling process including calculating a
plurality of solutions for filling non-conflicting orders, and
selecting one of the plurality of solutions according to a metric;
and informing users of a status of their price bids.
42-71.(canceled)
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of International
Application PCT/US2019/056727, filed Oct. 17, 2019, which claims
priority to U.S. Provisional Application No. 62/746,970 filed Oct.
17, 2018, entitled "Parceled Quantum Resources."
[0002] This application is also a continuation-in-part of
International Application PCT/US2019/054568, filed Oct. 3, 2019,
which claims priority to U.S. Provisional Application No.
62/740,808, filed Oct. 3, 2018, and to U.S. Provisional Application
No. 62/746,970, filed Oct. 17, 2018, both entitled "Parceled
Quantum Resources."
[0003] The entire contents of the above-referenced priority
applications are hereby incorporated by reference.
BACKGROUND
[0004] The following description relates to methods and systems
generally related to dynamically partitioning and virtualizing a
monolithic quantum-classical hybrid computing resource into
multiple different and independently-saleable (as a resource to a
user) parcels.
[0005] Quantum computers can perform computational tasks by storing
and processing information within quantum states of quantum
systems. For example, qubits (i.e., quantum bits) can be stored in
and represented by an effective two-level sub-manifold of a quantum
coherent physical system. A variety of physical systems have been
proposed for quantum computing applications. Examples include
superconducting circuits, trapped ions, spin systems and
others.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] FIG. 1 is a block diagram of an example computing
system.
[0007] FIG. 2 is a block diagram of a first example of a computing
system including a QPU resource monitoring, auctioning and
scheduling subsystem.
[0008] FIG. 3 is a high level block diagram of a second example
computing system including a QPU resource monitoring, auctioning
and scheduling subsystem.
[0009] FIG. 4 is a detailed block diagram of the second example
computing system of FIG. 3.
[0010] FIG. 5 is a flow chart showing example operation of the
second example computing system of FIG. 4.
[0011] FIG. 6 is a representation of an example control system
architecture for virtualized hybrid quantum classical
computing.
[0012] FIG. 7 is a representation of an example virtualizable
hybrid quantum-classical processor unit.
[0013] FIG. 8 is a representation of an example of two coherent
virtualizable hybrid quantum-classical processor units.
[0014] FIG. 9 is the hybrid quantum-classical processor unit of
FIG. 6 showing the Quantum Memory Management Unit in more
detail.
[0015] FIG. 10 is a representation of an example 4-processor
coherent virtualizable hybrid quantum-classical processor
system.
[0016] FIG. 11 is a representation of an example 8-processor
coherent virtualizable hybrid quantum-classical processor system
with a fully connected topology.
[0017] FIG. 12 is a representation of an example 8-processor
coherent virtualizable hybrid quantum-classical processor system
with a hypercube connected topology.
[0018] FIG. 13 is an illustration of an example of a multi-tenancy
enabled 4 qubit processor.
[0019] FIG. 14 is a representation of a method for enforcing
execution ordering between sequencers controlling different
qubits.
[0020] FIG. 15 is a flow chart showing an example quantum resource
order matching and filling process.
[0021] FIG. 16 is a flow chart showing an example process for
matching of quantum computing programs to particular subsets of
qubits on one or more quantum computation devices.
[0022] FIG. 17 is a ball and stick representation of an example
partitioned quantum processor unit.
[0023] FIG. 18 is a ball and stick illustration of a hierarchical
plaquette fusion heuristic.
[0024] FIG. 19 is a flow chart showing an example plaquette fusion
process.
[0025] FIG. 20 is a flow chart showing an example greedy plaquette
request allocation process.
[0026] FIGS. 21-24 are representations of graphic user interfaces
for web-based systems for the presentation, reservation, and
provisioning of individual qubits or sets of qubits from a larger
quantum computing system or chip to a particular user, according to
a first embodiment.
[0027] FIGS. 25-26 are representations of graphic user interfaces
for web-based systems for the presentation, reservation, and
provisioning of individual qubits or sets of qubits from a larger
quantum computing system or chip to a particular user, according to
a second embodiment.
DETAILED DESCRIPTION
[0028] In some aspects of what is described here, monolithic
quantum-classical hybrid computing resources may be dynamically
partitioned and virtualized into multiple different and
independently-saleable (as a resource to a user) parcels. These
parcels may comprise configurations of qubits and qubit-qubit links
on one or more quantum processor units for use by users for running
computer programs. This virtualization may extend from the qubit
level up through the control system, and including auxiliary
classical infra/compute resources for demanding hybrid workloads
and jobs. An order matching system can match a demand queue to a
set of available dynamically provisioned quantum-classical
resources, as part of a front-end system for a user to reserve,
provision, and purchase credits for, or time on, hybrid
quantum-classical resources of a certain desired performance level,
and for systems for monitoring and metering the use of these
resources to provide an account bill or usage statement.
Furthermore, in some instances, each qubit control signal may be
independently controlled by a thread of computation, implemented by
a CPU scheduling operations on the spooler. These threads are
synchronized, either with explicit signals, or through
deterministic timing. This makes it very natural to allocate a
collection of control threads (i.e. those associated with a
specific subset of qubits) to each user to natively support
multi-tenancy of the hybrid quantum-classical computing
resources.
[0029] A connected set of qubits, for example on a quantum
integrated circuit, is referred to herein as a plaquette. A
plaquette may also be described as a configuration of qubits and
qubit-qubit links on one or more quantum computation devices. An
epoch is the period of time during which a physical
quantum-classical hybrid computing system is provisioned in a
particular fixed configuration. The epoch time may be on the order
of hours, or minutes, or in embodiments seconds or fractions of
seconds.
[0030] In some instances, a computer system with quantum and
classical compute resources provisionable to multiple users, may
comprise: a user interface comprising a first classical computer
resource configured to enable a multiplicity of users to submit a
multiplicity of algorithms for a multiplicity of executions on a
hybrid quantum classical computer, and to enable the multiplicity
of users to interact with a plurality of results from the
corresponding multiplicity of algorithm executions; and an engine
coupled to the user interface, the engine comprising a second
classical computer resource configured to enable scheduling the
multiplicity of algorithm executions, composing a plurality of
plaquette resources from an aggregate system, monitoring the
availability of plaquette resources for computation, controlling a
multiplicity of plaquettes for executing computational steps of the
multiplicity of executions, and returning a multiplicity of
execution results to a user interface, wherein a plaquette is a
configuration of qubits and qubit-qubit links on one or more
quantum processor units; wherein the hybrid quantum-classical
computer comprises plaquettes operated as independent computational
elements. Furthermore, the first classical computer may be further
configured to enable the user to select a plaquette from available
plaquette resources on the computer system. Furthermore, the first
classical computer may be further configured to enable automated
plaquette selection for the user from available plaquette resources
on the computer system, the automated plaquette selection being
based on automated analysis of code the user wants to run.
[0031] In some instances, a method for calculating a price for use
of a configuration of qubits and qubit-qubit links on one or more
quantum processor units by a user for running a computer program,
may comprise: accessing a first database by a computer processor
unit to collect design characteristics of the one or more quantum
processor units, including inferred characteristics pertaining to
the expressiveness of the one or more quantum processor units,
wherein the inferred characteristics include instruction
availability; accessing a second database by the computer processor
unit to collect measurements of physical characteristics of the one
or more quantum processor units; accessing a third database by the
computer processor unit to collect characteristics of a specific
user's request; and determining the price using data collected from
the first, second and third databases.
[0032] In some instances, a computer system for calculating a price
for use of a configuration of qubits and qubit-qubit links on one
or more quantum processor units by a user for running a program,
may comprise: a first database for storing design characteristics
of the one or more quantum processor units, including inferred
characteristics pertaining to the expressiveness of the device,
wherein the inferred characteristics include instruction
availability; a second database for storing measurements of
physical characteristics of the one or more quantum processor
units; a third database for storing characteristics of a specific
user's request; and a computer processor unit for determining the
price, wherein the computer processor unit is linked to the first,
second and third databases for accessing input data for the
determining.
[0033] In some instances, a method of auctioning quantum computing
resources, may comprise: opening an auction and receiving price
bids electronically submitted by users, each price bid having an
order with a user desired qubit configuration, each order including
a number of qubits, a configuration of qubit connectivities, a
lower bound on qubit quality and one or more of a duration, a
particular segment of time and a minimum duration; rejecting a
specific price bid of the price bids unless the specific price bid
satisfies a criteria, the criteria including one or more of: a
minimum number of qubits and qubit-qubit links on one or more
quantum processor units, a start time of at least a fixed time in
the future, and a maximum duration; on satisfaction of one or more
specific criteria, closing the auction to any new price bids;
activating an order filling process, the order filling process
including calculating a plurality of solutions for filling
non-conflicting orders, and selecting one of the plurality of
solutions according to a metric; and informing users of a status of
their price bids. Furthermore, computer systems may be configured
to auction quantum computing resources as described above.
[0034] In some instances, a method of matching quantum computing
programs to particular subsets of qubits on one or more quantum
processor units, may comprise: receiving a quantum computing
program by an anonymizer unit, the anonymizer unit processing the
quantum computing program to remove distinguishing characteristics
to provide an anonymized quantum computing program; extracting by
an adviser unit of a basic structure of the anonymized quantum
computing program, the basic structure including qubit count, qubit
connectivity and minimum relaxation or coherence times for qubits;
comparing by the adviser unit the basic structure of the anonymized
quantum computing program with structures of a plurality of quantum
execution targets on the one or more quantum processor units,
wherein the plurality of quantum execution targets are subsets of
qubits and qubit-qubit links on one or more quantum processor
units, and determining appropriate quantum execution targets using
a heuristic, the heuristic including one or more of: matching
native gate sets, matching plaquette and desired topologies,
meeting gate activation fidelity requirements, meeting read-out
fidelity requirements, and meeting coherence time or relaxation
time requirements; and generating by the adviser unit of output
identifying recommended quantum execution targets for the quantum
computing program.
[0035] In some instances, a computer system for matching quantum
computing programs to particular subsets of qubits on one or more
quantum processor units, may comprise: (1) an anonymizer unit for:
receiving a quantum computing program by the anonymizer unit, the
anonymizer unit processing the quantum computing program to remove
distinguishing characteristics of a quantum computing program for
anonymizing the quantum computing program; and (2) an adviser for:
extracting a basic structure of the anonymized quantum computing
program, the basic structure including one or more of qubit count,
qubit connectivity, native gate sets, fidelity-type measurements of
native gates, readout fidelity, execution fidelity, relaxation or
coherence time measurements, randomized benchmarking results, run
quality of certain standard programs, historical quantum processor
unit performance drifts, and coherent and incoherent noise channel
measurements; comparing the basic structure of the anonymized
quantum computing program with structures of a plurality of quantum
execution targets, wherein the quantum execution targets are
subsets of qubits and qubit-qubit links on one or more quantum
computational devices, and determining appropriate quantum
execution targets using a heuristic, the heuristic including one or
more of: matching native gate sets, matching plaquette and desired
topologies, meeting fidelity requirements, and meeting coherence
time or relaxation time requirements; and generating output
identifying recommended quantum execution targets for the quantum
computing program.
[0036] In some instances, a method of plaquette fusion, wherein a
plaquette is a configuration of qubits and qubit-qubit links on one
or more quantum processor units, may comprise: receiving by a
computer processor unit a plurality of plaquette requests; sorting
by the computer processor unit the plaquette requests by plaquette
qubit count; fusing by the computer processor unit the plaquette
requests with plaquette qubit count below a predetermined integer
value, X, into one or more fused plaquette requests; and submitting
a request list to an allocation process, wherein the request list
includes the one or more fused plaquette requests and unfused
plaquette requests. Furthermore, computer systems may be configured
to fuse plaquettes as described above.
[0037] In some instances, a method of plaquette allocation, wherein
a plaquette is a configuration of qubits and qubit-qubit links on
one or more quantum processor units, may comprise: receiving by a
computer processor unit a plurality of plaquette requests; sorting
by the computer processor unit requests by one or more of highest
priority, highest revenue per qubit, and highest number of qubits;
initializing by the computer processor unit an empty quantum
processor unit (QPU) allocation; adding by the computer processor
unit the highest priority plaquette request to the allocation; and
determining by the computer processor unit if there are any
unassigned qubits in the allocation and (a) if there are no
unassigned qubits then submit the QPU allocation for the next
available epoch, (b) if there are unassigned qubits then further
determine if there are any unassigned requests that fit onto the
unassigned qubits and (i) if no unassigned requests fit then submit
the QPU allocation for the next available epoch, (ii) if unassigned
requests fit then add highest priority remaining request to the
allocation and repeat the determining. Furthermore, computer
systems may be configured to allocate plaquettes as described
above.
[0038] FIG. 1 is a block diagram of an example computing
environment 100. The example computing environment 100 shown in
FIG. 1 includes a computing system 101 and user devices 110A, 110B,
110C. A computing environment may include additional or different
features, and the components of a computing environment may operate
as described with respect to FIG. 1 or in another manner.
[0039] The example computing system 101 includes classical and
quantum computing resources and exposes their functionality to the
user devices 110A, 110B, 110C (referred to collectively as "user
devices 110"). The computing system 101 shown in FIG. 1 includes
one or more servers 108, quantum computing systems 103A, 103B, a
local network 109 and other resources 107. The computing system 101
may also include one or more user devices (e.g., the user device
110A) as well as other features and components. A computing system
may include additional or different features, and the components of
a computing system may operate as described with respect to FIG. 1
or in another manner.
[0040] The example computing system 101 can provide services to the
user devices 110, for example, as a cloud-based or remote-accessed
computer system, as a distributed computing resource, as a
supercomputer or another type of high-performance computing
resource, or in another manner. The computing system 101 or the
user devices 110 may also have access to one or more other quantum
computing systems (e.g., quantum computing resources that are
accessible through the wide area network 115, the local network 109
or otherwise).
[0041] The user devices 110 shown in FIG. 1 may include one or more
classical processor, memory, user interfaces, communication
interfaces, and other components. For instance, the user devices
110 may be implemented as laptop computers, desktop computers,
smartphones, tablets or other types of computer devices. In the
example shown in FIG. 1, to access computing resources of the
computing system 101, the user devices 110 send information (e.g.,
programs, instructions, commands, requests, input data, etc.) to
the servers 108; and in response, the user devices 110 receive
information (e.g., application data, output data, prompts, alerts,
notifications, results, etc.) from the servers 108. The user
devices 110 may access services of the computing system 101 in
another manner, and the computing system 101 may expose computing
resources in another manner.
[0042] In the example shown in FIG. 1, the local user device 110A
operates in a local environment with the servers 108 and other
elements of the computing system 101. For instance, the user device
110A may be co-located with (e.g., located within 0.5 to 1 km of)
the servers 108 and possibly other elements of the computing system
101. As shown in FIG. 1, the user device 110A communicates with the
servers 108 through a local data connection.
[0043] The local data connection in FIG. 1 is provided by the local
network 109. For example, some or all of the servers 108, the user
device 110A, the quantum computing systems 103A, 103B and the other
resources 107 may communicate with each other through the local
network 109. In some implementations, the local network 109
operates as a communication channel that provides one or more
low-latency communication pathways from the server 108 to the
quantum computer systems 103A, 103B (or to one or more of the
elements of the quantum computer systems 103A, 103B). The local
network 109 can be implemented, for instance, as a wired or
wireless Local Area Network, an Ethernet connection, or another
type of wired or wireless connection. The local network 109 may
include one or more wired or wireless routers, wireless access
points (WAPs), wireless mesh nodes, switches, high-speed cables, or
a combination of these and other types of local network hardware
elements. In some cases, the local network 109 includes a
software-defined network that provides communication among virtual
resources, for example, among an array of virtual machines
operating on the server 108 and possibly elsewhere.
[0044] In the example shown in FIG. 1, the remote user devices
110B, 110C operate remote from the servers 108 and other elements
of the computing system 101. For instance, the user devices 110B,
110C may be located at a remote distance (e.g., more than 1 km, 10
km, 100 km, 1,000 km, 10,000 km, or farther) from the servers 108
and possibly other elements of the computing system 101. As shown
in FIG. 1, each of the user devices 110B, 110C communicates with
the servers 108 through a remote data connection.
[0045] The remote data connection in FIG. 1 is provided by a wide
area network 115, which may include, for example, the Internet or
another type of wide area communication network. In some cases,
remote user devices use another type of remote data connection
(e.g., satellite-based connections, a cellular network, a virtual
private network, etc.) to access the servers 108. The wide area
network 115 may include one or more internet servers, firewalls,
service hubs, base stations, or a combination of these and other
types of remote networking elements. Generally, the computing
environment 100 can be accessible to any number of remote user
devices.
[0046] The example servers 108 shown in FIG. 1 can manage
interaction with the user devices 110 and utilization of the
quantum and classical computing resources in the computing system
101. For example, based on information from the user devices 110,
the servers 108 may delegate computational tasks to the quantum
computing systems 103A, 103B and the other resources 107; the
servers 108 can then send information to the user devices 110 based
on output data from the computational tasks performed by the
quantum computing systems 103A, 103B and the other resources
107.
[0047] As shown in FIG. 1, the servers 108 are classical computing
resources that include classical processors 111 and memory 112. The
servers 108 may also include one or more communication interfaces
that allow the servers to communicate via the local network 109,
the wide area network 115 and possibly other channels. In some
implementations, the servers 108 may include a host server, an
application server, a virtual server or a combination of these and
other types of servers. The servers 108 may include additional or
different features, and may operate as described with respect to
FIG. 1 or in another manner.
[0048] The classical processors 111 can include various kinds of
apparatus, devices, and machines for processing data, including, by
way of example, a microprocessor, a central processing unit (CPU),
a graphics processing unit (GPU), an FPGA (field programmable gate
array), an ASIC (application specific integrated circuit), or
combinations of these. The memory 112 can include, for example, a
random access memory (RAM), a storage device (e.g., a writable
read-only memory (ROM) or others), a hard disk, or another type of
storage medium. The memory 112 can include various forms of
volatile or non-volatile memory, media and memory devices, etc.
[0049] Each of the example quantum computing systems 103A, 103B
operates as a quantum computing resource in the computing system
101. The other resources 107 may include additional quantum
computing resources (e.g., quantum computing systems, quantum
virtual machines (QVMs) or quantum simulators) as well as classical
(non-quantum) computing resources such as, for example, digital
microprocessors, specialized co-processor units (e.g., graphics
processing units (GPUs), cryptographic co-processors, etc.),
special purpose logic circuitry (e.g., field programmable gate
arrays (FPGAs), application-specific integrated circuits (ASICs),
etc.), systems-on-chips (SoCs), etc., or combinations of these and
other types of computing modules.
[0050] In some implementations, the servers 108 generate programs,
identify appropriate computing resources (e.g., a QPU or QVM) in
the computing system 101 to execute the programs, and send the
programs to the identified resources for execution. For example,
the servers 108 may send programs to the quantum computing system
103A, the quantum computing system 103B or any of the other
resources 107. The programs may include classical programs, quantum
programs, hybrid classical/quantum programs, and may include any
type of function, code, data, instruction set, etc.
[0051] In some instances, programs can be formatted as source code
that can be rendered in human-readable form (e.g., as text) and can
be compiled, for example, by a compiler running on the servers 108,
on the quantum computing systems 103, or elsewhere. In some
instances, programs can be formatted as compiled code, such as, for
example, binary code (e.g., machine-level instructions) that can be
executed directly by a computing resource. Each program may include
instructions corresponding to computational tasks that, when
performed by an appropriate computing resource, generate output
data based on input data. For example, a program can include
instructions formatted for a quantum computer system, a quantum
virtual machine, a digital microprocessor, co-processor or other
classical data processing apparatus, or another type of computing
resource.
[0052] In some cases, a program may be expressed in a
hardware-independent format. For example, quantum machine
instructions may be provided in a quantum instruction language such
as Quil, described in the publication "A Practical Quantum
Instruction Set Architecture," arXiv:1608.03355v2, dated Feb. 17,
2017, or another quantum instruction language. For instance, the
quantum machine instructions may be written in a format that can be
executed by a broad range of quantum processing units or quantum
virtual machines. In some cases, a program may be expressed in
high-level terms of quantum logic gates or quantum algorithms, in
lower-level terms of fundamental qubit rotations and controlled
rotations, or in another form. In some cases, a program may be
expressed in terms of control signals (e.g., pulse sequences,
delays, etc.) and parameters for the control signals (e.g.,
frequencies, phases, durations, channels, etc.). In some cases, a
program may be expressed in another form or format.
[0053] In some implementations, the servers 108 include one or more
compilers that convert programs between formats. For example, the
servers 108 may include a compiler that converts
hardware-independent instructions to binary programs for execution
by the quantum computing systems 103A, 103B. In some cases, a
compiler can compile a program to a format that targets a specific
quantum resource in the computer system 101. For example, a
compiler may generate a different binary program (e.g., from the
same source code) depending on whether the program is to be
executed by the quantum computing system 103A or the quantum
computing system 103B.
[0054] In some cases, a compiler generates a partial binary program
that can be updated, for example, based on specific parameters. For
instance, if a quantum program is to be executed iteratively on a
quantum computing system with varying parameters on each iteration,
the compiler may generate the binary program in a format that can
be updated with specific parameter values at runtime (e.g., based
on feedback from a prior iteration, or otherwise). In some cases, a
compiler generates a full binary program that does not need to be
updated or otherwise modified for execution.
[0055] In some implementations, the servers 108 generate a schedule
for executing programs, allocate computing resources in the
computing system 101 according to the schedule, and delegate the
programs to the allocated computing resources. The servers 108 can
receive, from each computing resource, output data from the
execution of each program. Based on the output data, the servers
108 may generate additional programs that are then added to the
schedule, output data that is provided back to a user device 110,
or perform another type of action.
[0056] In some implementations, all or part of the computing
environment operates as a cloud-based quantum computing (QC)
environment, and the servers 108 operate as a host system for the
cloud-based QC environment. The cloud-based QC environment may
include software elements that operate on both the user devices 110
and the computer system 101 and interact with each other over the
wide area network 115. For example, the cloud-based QC environment
may provide a remote user interface, for example, through a browser
or another type of application on the user devices 110. The remote
user interface may include, for example, a graphical user interface
or another type of user interface that obtains input provided by a
user of the cloud-based QC environment. In some cases the remote
user interface includes, or has access to, one or more application
programming interfaces (APIs), command line interfaces, graphical
user interfaces, or other elements that expose the services of the
computer system 101 to the user devices 110.
[0057] In some cases, the cloud-based QC environment may be
deployed in a "serverless" computing architecture. For instance,
the cloud-based QC environment may provide on-demand access to a
shared pool of configurable computing resources (e.g., networks,
servers, storage, applications, services, quantum computing
resources, classical computing resources, etc.) that can be
provisioned for requests from user devices 110. Moreover, the
cloud-based computing systems 104 may include or utilize other
types of computing resources, such as, for example, edge computing,
fog computing, etc.
[0058] In an example implementation of a cloud-based QC
environment, the servers 108 may operate as a cloud provider that
dynamically manages the allocation and provisioning of physical
computing resources (e.g., GPUs, CPUs, QPUs, etc.). Accordingly,
the servers 108 may provide services by defining virtualized
resources for each user account. For instance, the virtualized
resources may be formatted as virtual machine images, virtual
machines, containers, or virtualized resources that can be
provisioned for a user account and configured by a user. In some
cases, the cloud-based QC environment is implemented using a
resource such as, for example, OPENSTACK.RTM.. OPENSTACK.RTM. is an
example of a software platform for cloud-based computing, which can
be used to provide virtual servers and other virtual computing
resources for users.
[0059] In some cases, the server 108 stores quantum machine images
(QMI) for each user account. A quantum machine image may operate as
a virtual computing resource for users of the cloud-based QC
environment. For example, a QMI can provide a virtualized
development and execution environment to develop and run programs
(e.g., quantum programs or hybrid classical/quantum programs). When
a QMI operates on the server 108, the QMI may engage either of the
quantum processor units 102A, 102B, and interact with a remote user
device (110B or 110C) to provide a user programming environment.
The QMI may operate in close physical proximity to and have a
low-latency communication link with the quantum computing systems
103A, 103B. In some implementations, remote user devices connect
with QMIs operating on the servers 108 through secure shell (SSH)
or other protocols over the wide area network 115.
[0060] In some implementations, all or part of the computing system
101 operates as a hybrid computing environment. For example,
quantum programs can be formatted as hybrid classical/quantum
programs that include instructions for execution by one or more
quantum computing resources and instructions for execution by one
or more classical resources. The servers 108 can allocate quantum
and classical computing resources in the hybrid computing
environment, and delegate programs to the allocated computing
resources for execution. The quantum computing resources in the
hybrid environment may include, for example, one or more quantum
processing units (QPUs), one or more quantum virtual machines
(QVMs), one or more quantum simulators, or possibly other types of
quantum resources. The classical computing resources in the hybrid
environment may include, for example, one or more digital
microprocessors, one or more specialized co-processor units (e.g.,
graphics processing units (GPUs), cryptographic co-processors,
etc.), special purpose logic circuitry (e.g., field programmable
gate arrays (FPGAs), application-specific integrated circuits
(ASICs), etc.), systems-on-chips (SoCs), or other types of
computing modules.
[0061] In some examples, hybrid classical/quantum algorithms may
employ a variational execution model in order to accomplish tasks
such as, for example, solving combinatorial optimization problems
or simulating quantum chemistry. To execute hybrid
classical/quantum algorithms according to this model, the server
108 can generate an initial quantum program (e.g., based on a
proposed solution to a problem, starting with an initial guess,
etc.), and send the initial quantum program to quantum computer
resource (e.g., the quantum computer system 103A, the quantum
computer system 103B, a QVM, or a combination of them) for
execution. Then, from the output of executing the initial quantum
program, a classical optimizer running on the server 108 (or
another classical computer resource) may update the quantum program
for the next round of iteration on the quantum computer resource.
Depending on the difficulty of the problem, the quality of the
quantum computer resource, and other factors, the iteration loop
may be repeated many times before completing the computational
task. In some implementations, low-latency hybrid classical/quantum
computing can be achieved, for example, when a QMI operates on a
classical machine that is physically located close to a QPU.
[0062] In some cases, the servers 108 can select the type of
computing resource (e.g., quantum or classical) to execute an
individual program, or part of a program, in the computing system
101. For example, the servers 108 may select a particular quantum
processing unit (QPU) or other computing resource based on
availability of the resource, speed of the resource, information or
state capacity of the resource, a performance metric (e.g., process
fidelity) of the resource, or based on a combination of these and
other factors.
[0063] In some cases, the servers 108 can perform load balancing,
resource testing and calibration, and other types of operations to
improve or optimize computing performance.
[0064] Each of the example quantum computing systems 103A, 103B
shown in FIG. 1 can perform quantum computational tasks by
executing quantum machine instructions (e.g., a binary program
compiled for the quantum computing system). In some
implementations, a quantum computing system can perform quantum
computation by storing and manipulating information within quantum
states of a composite quantum system. For example, qubits (i.e.,
quantum bits) can be stored in and represented by an effective
two-level sub-manifold of a quantum coherent physical system. In
some instances, quantum logic can be executed in a manner that
allows large-scale entanglement within the quantum system. Control
signals can manipulate the quantum states of individual qubits and
the joint states of multiple qubits. In some instances, information
can be read out from the composite quantum system by measuring the
quantum states of the qubits. In some implementations, the quantum
states of the qubits are read out by measuring the transmitted or
reflected signal from auxiliary quantum devices that are coupled to
individual qubits.
[0065] In some implementations, a quantum computing system can
operate using gate-based models for quantum computing. For example,
the qubits can be initialized in an initial state, and a quantum
logic circuit comprised of a series of quantum logic gates can be
applied to transform the qubits and extract measurements
representing the output of the quantum computation. Individual
qubits may be controlled by single-qubit quantum logic gates, and
pairs of qubits may be controlled by two-qubit quantum logic gates
(e.g., entangling gates that are capable of generating entanglement
between the pair of qubits). In some implementations, a quantum
computing system can operate using adiabatic or annealing models
for quantum computing. For instance, the qubits can be initialized
in an initial state, and the controlling Hamiltonian can be
transformed adiabatically by adjusting control parameters to
another state that can be measured to obtain an output of the
quantum computation.
[0066] In some models, fault-tolerance can be achieved by applying
a set of high-fidelity control and measurement operations to the
qubits. For example, quantum error correcting schemes can be
deployed to achieve fault-tolerant quantum computation. Other
computational regimes may be used; for example, quantum computing
systems may operate in non-fault-tolerant regimes. In some
implementations, a quantum computing system is constructed and
operated according to a scalable quantum computing architecture.
For example, in some cases, the architecture can be scaled to a
large number of qubits to achieve large-scale general purpose
coherent quantum computing. Other architectures may be used; for
example, quantum computing systems may operate in small-scale or
non-scalable architectures.
[0067] The example quantum computing system 103A shown in FIG. 1
includes a quantum processing unit 102A and a control system 105A,
which controls the operation of the quantum processing unit 102A.
Similarly, the example quantum computing system 103B includes a
quantum processing unit 102B and a control system 105B, which
controls the operation of a quantum processing unit 102B. A quantum
computing system may include additional or different features, and
the components of a quantum computing system may operate as
described with respect to FIG. 1 or in another manner.
[0068] In some instances, all or part of the quantum processing
unit 102A functions as a quantum processor, a quantum memory, or
another type of subsystem. In some examples, the quantum processing
unit 102A includes a quantum circuit system. The quantum circuit
system may include qubit devices, readout devices and possibly
other devices that are used to store and process quantum
information. In some cases, the quantum processing unit 102A
includes a superconducting circuit, and the qubit devices are
implemented as circuit devices that include Josephson junctions,
for example, in superconducting quantum interference device (SQUID)
loops or other arrangements, and are controlled by radio-frequency
signals, microwave signals, and bias signals delivered to the
quantum processing unit 102A. In some cases, the quantum processing
unit 102A includes an ion trap system, and the qubit devices are
implemented as trapped ions controlled by optical signals delivered
to the quantum processing unit 102A. In some cases, the quantum
processing unit 102A includes a spin system, and the qubit devices
are implemented as nuclear or electron spins controlled by
microwave or radio-frequency signals delivered to the quantum
processing unit 102A. The quantum processing unit 102A may be
implemented based on another physical modality of quantum
computing.
[0069] The quantum processing unit 102A may include, or may be
deployed within, a controlled environment. The controlled
environment can be provided, for example, by shielding equipment,
cryogenic equipment, and other types of environmental control
systems. In some examples, the components in the quantum processing
unit 102A operate in a cryogenic temperature regime and are subject
to very low electromagnetic and thermal noise. For example,
magnetic shielding can be used to shield the system components from
stray magnetic fields, optical shielding can be used to shield the
system components from optical noise, thermal shielding and
cryogenic equipment can be used to maintain the system components
at controlled temperature, etc.
[0070] In some implementations, the example quantum processing unit
102A can process quantum information by applying control signals to
the qubits in the quantum processing unit 102A. The control signals
can be configured to encode information in the qubits, to process
the information by performing quantum logic gates or other types of
operations, or to extract information from the qubits. In some
examples, the operations can be expressed as single-qubit quantum
logic gates, two-qubit quantum logic gates, or other types of
quantum logic gates that operate on one or more qubits. A quantum
logic circuit, which includes a sequence of quantum logic
operations, can be applied to the qubits to perform a quantum
algorithm. The quantum algorithm may correspond to a computational
task, a hardware test, a quantum error correction procedure, a
quantum state distillation procedure, or a combination of these and
other types of operations.
[0071] The example control system 105A includes controllers 106A
and signal hardware 104A. Similarly, control system 105B includes
controllers 106B and signal hardware 104B. All or part of the
control systems 105A, 105B can operate in a room-temperature
environment or another type of environment, which may be located
near the respective quantum processing units 102A, 102B. In some
cases, the control systems 105A, 105B include classical computers,
signaling equipment (microwave, radio, optical, bias, etc.),
electronic systems, vacuum control systems, refrigerant control
systems or other types of control systems that support operation of
the quantum processing units 102A, 102B.
[0072] The control systems 105A, 105B may be implemented as
distinct systems that operate independent of each other. In some
cases, the control systems 105A, 105B may include one or more
shared elements; for example, the control systems 105A, 105B may
operate as a single control system that operates both quantum
processing units 102A, 102B. Moreover, a single quantum computer
system may include multiple quantum processing units, which may
operate in the same controlled (e.g., cryogenic) environment or in
separate environments.
[0073] The example signal hardware 104A includes components that
communicate with the quantum processing unit 102A. The signal
hardware 104A may include, for example, waveform generators,
amplifiers, digitizers, high-frequency sources, DC sources, AC
sources, etc. The signal hardware may include additional or
different features and components. In the example shown, components
of the signal hardware 104A are adapted to interact with the
quantum processing unit 102A. For example, the signal hardware 104A
can be configured to operate in a particular frequency range,
configured to generate and process signals in a particular format,
or the hardware may be adapted in another manner.
[0074] In some instances, one or more components of the signal
hardware 104A generate control signals, for example, based on
control information from the controllers 106A. The control signals
can be delivered to the quantum processing unit 102A during
operation of the quantum computing system 103A. For instance, the
signal hardware 104A may generate signals to implement quantum
logic operations, readout operations or other types of operations.
As an example, the signal hardware 104A may include arbitrary
waveform generators (AWGs) that generate electromagnetic waveforms
(e.g., microwave or radio-frequency) or laser systems that generate
optical waveforms. The waveforms or other types of signals
generated by the signal hardware 104A can be delivered to devices
in the quantum processing unit 102A to operate qubit devices,
readout devices, bias devices, coupler devices or other types of
components in the quantum processing unit 102A.
[0075] In some instances, the signal hardware 104A receives and
processes signals from the quantum processing unit 102A. The
received signals can be generated by the execution of a quantum
program on the quantum computing system 103A. For instance, the
signal hardware 104A may receive signals from the devices in the
quantum processing unit 102A in response to readout or other
operations performed by the quantum processing unit 102A. Signals
received from the quantum processing unit 102A can be mixed,
digitized, filtered, or otherwise processed by the signal hardware
104A to extract information, and the information extracted can be
provided to the controllers 106A or handled in another manner. In
some examples, the signal hardware 104A may include a digitizer
that digitizes electromagnetic waveforms (e.g., microwave or
radio-frequency) or optical signals, and a digitized waveform can
be delivered to the controllers 106A or to other signal hardware
components. In some instances, the controllers 106A process the
information from the signal hardware 104A and provide feedback to
the signal hardware 104A; based on the feedback, the signal
hardware 104A can in turn generate new control signals that are
delivered to the quantum processing unit 102A.
[0076] In some implementations, the signal hardware 104A includes
signal delivery hardware that interfaces with the quantum
processing unit 102A. For example, the signal hardware 104A may
include filters, attenuators, directional couplers, multiplexers,
diplexers, bias components, signal channels, isolators, amplifiers,
power dividers and other types of components. In some instances,
the signal delivery hardware performs preprocessing, signal
conditioning, or other operations to the control signals to be
delivered to the quantum processing unit 102A. In some instances,
signal delivery hardware performs preprocessing, signal
conditioning or other operations on readout signals received from
the quantum processing unit 102A.
[0077] The example controllers 106A communicate with the signal
hardware 104A to control operation of the quantum computing system
103A. The controllers 106A may include classical computing hardware
that directly interface with components of the signal hardware
104A. The example controllers 106A may include classical
processors, memory, clocks, digital circuitry, analog circuitry,
and other types of systems or subsystems. The classical processors
may include one or more single- or multi-core microprocessors,
digital electronic controllers, special purpose logic circuitry,
e.g., an FPGA (field programmable gate array) or an ASIC
(application specific integrated circuit), or other types of data
processing apparatus. The memory may include any type of volatile
or non-volatile memory or another type of computer storage medium.
The controllers 106A may also include one or more communication
interfaces that allow the controllers 106A to communicate via the
local network 109 and possibly other channels. The controllers 106A
may include additional or different features and components.
[0078] In some implementations, the controllers 106A include memory
or other components that store quantum state information, for
example, based on qubit readout operations performed by the quantum
computing system 103A. For instance, the states of one or more
qubits in the quantum processing unit 102A can be measured by qubit
readout operations, and the measured state information can be
stored in a cache or other type of memory system in or more of the
controllers 106A. In some cases, the measured state information is
subsequently used in the execution of a quantum program, a quantum
error correction procedure, a quantum processing unit (QPU)
calibration or testing procedure, or another type of quantum
process.
[0079] In some implementations, the controllers 106A include memory
or other components that store a quantum program containing quantum
machine instructions for execution by the quantum computing system
103A. In some instances, the controllers 106A can interpret the
quantum machine instructions and perform hardware-specific control
operations according to the quantum machine instructions. For
example, the controllers 106A may cause the signal hardware 104A to
generate control signals that are delivered to the quantum
processing unit 102A to execute the quantum machine
instructions.
[0080] In some instances, the controllers 106A extract qubit state
information from qubit readout signals, for example, to identify
the quantum states of qubits in the quantum processing unit 102A or
for other purposes. For example, the controllers may receive the
qubit readout signals (e.g., in the form of analog waveforms) from
the signal hardware 104A, digitize the qubit readout signals, and
extract qubit state information from the digitized signals. In some
cases, the controllers 106A compute measurement statistics based on
qubit state information from multiple shots of a quantum program.
For example, each shot may produce a bitstring representing qubit
state measurements for a single execution of the quantum program,
and a collection of bitsrings from multiple shots may be analyzed
to compute quantum state probabilities.
[0081] In some implementations, the controllers 106A include one or
more clocks that control the timing of operations. For example,
operations performed by the controllers 106A may be scheduled for
execution over a series of clock cycles, and clock signals from one
or more clocks can be used to control the relative timing of each
operation or groups of operations. In some implementations, the
controllers 106A may include classical computer resources that
perform some or all of the operations of the servers 108 described
above. For example, the controllers 106A may operate a compiler to
generate binary programs (e.g., full or partial binary programs)
from source code; the controllers 106A may include an optimizer
that performs classical computational tasks of a hybrid
classical/quantum program; the controllers 106A may update binary
programs (e.g., at runtime) to include new parameters based on an
output of the optimizer, etc.
[0082] The other quantum computer system 103B and its components
(e.g., the quantum processing unit 102B, the signal hardware 104B
and controllers 106B) can be implemented as described above with
respect to the quantum computer system 103A; in some cases, the
quantum computer system 103B and its components may be implemented
or may operate in another manner.
[0083] In some implementations, the quantum computer systems 103A,
103B are disparate systems that provide distinct modalities of
quantum computation. For example, the computer system 101 may
include both an adiabatic quantum computer system and a gate-based
quantum computer system. As another example, the computer system
101 may include a superconducting circuit-based quantum computer
system and an ion trap-based quantum computer system. In such
cases, the computer system 101 may utilize each quantum computing
system according to the type of quantum program that is being
executed, according to availability or capacity, or based on other
considerations.
[0084] FIGS. 2 & 3 are schematic representations of high level
block diagrams 200, 300 of example computing systems including QPU
resource monitoring, auctioning and scheduling subsystems. In some
implementations, elements of the example computing environment 100
shown in FIG. 1 can be cast with an architecture illustrated by the
example systems 200, 300 & 400 shown in FIGS. 2, 3 & 4,
respectively. The example system 200 shown in FIG. 2 provides users
201 access to the QPU control system 212 via the cloud, the
internet, or some other communication link, which is comparable to
user device 110 access to quantum computing systems 103 in FIG. 1.
FIG. 2 also includes plaquette analysis module 205 and resource
auctioning and scheduling system 206, which may be provided on
servers 108 in FIG. 1.
[0085] Hardware and software systems for virtualized
quantum-classical computing are described as follows with reference
to the figures. The system capabilities and core concepts that
underpin the virtualization of quantum-classical compute systems
and their provisioning to multiple simultaneous users are covered
starting from the qubit level (for example, the quantum integrated
circuit) and including: the dynamical creation and definition of
qubit plaquettes with specific performance attributes and
characteristics; the hosting on a single QPU multiple user
instances connected to those plaquettes and the provisioning of
classical resources to support each such instance in a quantum
classical architecture, as demanded by the specific job or
user.
[0086] In some embodiments a quantum computing system may be
configured such that one or more of the following apply: the number
of concurrent computations can be larger than one; concurrent
computations are logically independent instances of hybrid
quantum-classical algorithms; the number of concurrent computations
is larger than the number of aggregated quantum computation
resources; one aggregated quantum resource is an entire processor
of superconducting qubits (likewise for pother qubit types
including ions, spins, nitrogen vacancies (NVs), etc.); the time
ordering of concurrent execution of computations is managed by a
resource manager; the apportionment of multiple partial resources
(plaquettes) from a single aggregate quantum system for computation
is managed by a resource manager; the constitution and/or
properties of multiple partial resources (plaquettes) apportioned
from a single aggregate quantum system for computation may be
modified by a resource manager.
[0087] Users want to run programs on a quantum processor unit
(QPU), but often their programs far underutilize the total
collection of quantum resources available. Understanding the
resource utilization of individual programs, together with the
resource subset availability on the QPU, user's jobs can be matched
with subsets of the available resources to most effectively utilize
the QPU. A representation of an example hybrid quantum-classical
computing system 200 with subsystems for parceling quantum
resources to multiple users 201 is provided in FIG. 2. Users 201
are the external customers for resources. Through the offer
interface 202 users can view the available QPU resources including
information about embeddable plaquettes and qubit qualities;
historic price information may also be provided. On the order
interface 203 users can submit an order, or bid, for a certain
number of epochs running on a plaquette of a certain size,
connectivity and quality of qubits. In the case of an auction-based
process, the order interface allows the user to see the success of
previously submitted bids and to re-submit a new bid for the next
round.
[0088] The resource, auctioning and scheduling subsystem 206
provides the following functions: matches orders to available
resources and their usage/access schedule (order book job schedule
207); determines the pricing of plaquettes; accepts or rejects
orders submitted by users; manages temporal access control to QPU
resources (access control 209); and handles the bookkeeping of
consumed epochs on resources (update bookkeeping 208). A usage
database 204 stores the record of consumed epochs on plaquettes for
each user along with the corresponding price. A plaquette analysis
module 205 tracks the properties of available QPU plaquettes over
time (across recalibrations of the QPU). A QPU characteristics
database 210 stores the quality metrics of each qubit and gate on
each QPU. Calibration agents 211 periodically execute recalibration
jobs on each qubit of each QPU 212, measure the current
performance, and provide the data to the QPU characteristics
database 210. The control systems and their connected QPUs 212
include both the classical and quantum compute resources as well as
everything required for the interaction of the hybrid
resources.
[0089] FIG. 3 is a high level block diagram of a second example
computing system 300 including a QPU resource monitoring,
auctioning and scheduling subsystem. System 300 comprises a user
interface 301, an engine 302 and QPU plaquettes 303. The user
interface 301 comprises a classical computer resource configured to
enable: a multitude of users to compose a multitude of algorithms,
compile and/or submit the multitude of algorithms for a multitude
of executions, receive and/or interact with a plurality of results
from the multitude of algorithm executions, and receive and/or
interact with information about the system. Some or all of these
user interactions may be simultaneous.
[0090] The engine 302 comprises a classical computer resource
configured to enable: scheduling a multitude of algorithm requests;
composing a multitude of plaquette resources from an aggregate
system; monitoring and/or managing the availability of plaquettes
for computation; instructing a multitude of QPU plaquettes on a
plurality of computation steps; and returning a multitude of
execution results. The engine 302 may include a database for
storing information.
[0091] The QPU plaquettes 303 comprise multiple quantum-classical
hybrid systems operated as independent computational elements,
which may be parts of an aggregate system. The QPU plaquettes are
configured to allow a multitude of computation instructions to be
concurrently executed across a plurality of QPU plaquettes. The QPU
plaquettes may have features at physical or logical boundaries
between resources which reduce coupling between plaquettes, as
described in more detail below.
[0092] FIG. 4 is a detailed block diagram of the example computing
system of FIG. 3; hybrid quantum-classical computing system 400
comprises the following elements. A User interface 401 comprises: a
web interface; a command line (e.g. SSH) interface; a GUI interface
and/or a multitude of visualizations; and provides access a system
information interface 402 and programming system interface 403. The
system information interface 402 provides: visualizations of
available resources, including information about potential
plaquettes, benchmark information on the plaquettes and component
qubits, system availability and scheduling. The system information
interface may be periodically updated, for instance by queries to
the device database 411.
[0093] The system programming interface provides access to features
such as software packages, quantum computing simulation
capabilities, compilation capabilities, error checking and/or
debugging capabilities, and resource estimators, such as a
plaquette generator 406 and/or schedule estimates, for example by
providing access to a request database 404. The request database is
configured to store requests from a multitude of users, and
organize the requests by one or more of the required resources,
requested time for use of QPU and/or duration, etc. The scheduler
405 is configured to optimize: parcel resource allocation of
requests, time ordering of requests including concurrent execution
of requests, and timing of recalibration, all given some objective
function(s). For example, the timing of recalibration may be
optimized to maximize available run time for jobs, optimized to
provide anticipated performance at or above a fixed criteria based
on historical performance (which may be recalibration at fixed time
intervals), optimized to make system available for highest priority
jobs, etc. Information about the system may be used for these
optimizations, for example system benchmarks (available from device
database 411 and/or current (or future) availability (available
from resource manager 407).
[0094] Plaquette generator 406 is configured to: encode the
properties of an aggregate quantum resource, such as its
connectivity and/or benchmarks, as a graph network to represent
potential plaquettes; solve for suitable graph configurations for a
multitude of concurrent algorithm requests; consider a weighted
graph distance metric that includes benchmarks in the weights; and
compute properties of plaquettes such as route problems, like
minimum spanning tree and/or shortest path and/or longest path
and/or statistical properties of graphs. The generator 406 may be
employed by users through user interface 401 or programming
interface 403.
[0095] Resource manager 407 is configured to: features: monitor the
QPU for available resources; assign QPU resources to "unavailable"
based on specified criteria, such as poor fidelity, recalibration,
etc.; assign QPU resources to "available"; and instruct the
formation of plaquettes from a pool of QPU resources. Note that
parcels are re-constituted, if necessary, for a given execution.
Plaquette formation may include hardware reconfiguration, such as:
bias adjusted for tunable couplers to cause more/less coupling
between qubits; room temperature switch activated to change signal
paths; adjustments to control parameters (e.g. modular control IP).
Furthermore, plaquette formation may include software
reconfiguration, such as: memory register addresses may be set; CPU
threads may be created or deleted; virtual machine instances may be
created or deleted. Furthermore, memory addresses that translate
virtual resources to physical resources may be set. Furthermore,
the resource manager may be embedded in the control system of the
aggregate quantum computer, for instance in a host computer or on
an FPGA.
[0096] Execution job database 408 may comprise a time-ordered set
of executions for the QPU and may be implemented as a stack
(queue). Furthermore, the database may be embedded in the control
system of the aggregate quantum computer, for instance in a host
computer or an FPGA. Furthermore, the database may be re-ordered by
the scheduler 405.
[0097] Execution engine 409 is configured to send instructions to a
multitude of QPU parcels and receive results from a multitude of
QPU parcels.
[0098] The QPU plaquettes/parcels 410 may comprise: conventional
information processing capabilities; conventional, heterogeneous
processing capabilities (e.g. GPUs); sufficient control system to
operate a parcel of quantum resources. The QPU parcels may be
characterized by: a static relationship between control system and
quantum resource (i.e. fixed signal paths); or a dynamic
relationship between control system and quantum resource (i.e.
switches). The QPU parcels may be configured to enable adjusting
control parameters when re-allocation of parcelling is indicated by
the resource manager 407. Note that a pool of QPU parcels may be
considered aggregated if run-time execution information and/or
quantum information could be exchanged between them.
[0099] Device database 411 may be configured to: store results from
benchmarking tests on a multitude of parcels; store results from
selected executions on a multitude of parcels; include
meta-information about devices in the system, for instance device
connectivity and/or status. Results database 412 may be configured
to: store the results of executions from a multitude of QPU
parcels; organize results according to information pertaining to
the job request.
[0100] FIG. 5 is a flow chart showing an example operation of the
computing system of FIG. 4. Information may be provided to the user
(501) through a user interface (401) where the data may include:
information about potential plaquettes; information about
benchmarks; information about system availability; and information
about scheduling. Relevant data may be stored in a database (411).
Historical data and/or trends may be stored and/or accessed. Data
may be stored in a relational database. Data may be average and/or
expected values. Data may include statistical confidence intervals.
Information may be provided to the user through a system
information interface (402) and may include: visualizations, for
instance of benchmark results; representations of quantum device
connectivity, e.g. graphical; and information about the results or
expected results of algorithms run on the system and/or on
plaquettes. The user may interact with this interface through a web
browser and/or GUI and/or API.
[0101] A user may compose an algorithm (502) through a user
interface (401) and/or through a system programming interface
(403): The user may utilize pre-developed software packages to
compose an algorithm, for example: Rigetti's open source Grove
package contains a multitude of known quantum algorithms
implemented in Quil. These may be made available to users, through
a gamming interface. The users may incorporate these as subroutines
and/or modify them as they determine. Furthermore, third parties
may develop software that is made available to users through the
system programming interface (403). The user may utilize simulation
capabilities to compose an algorithm. For example, Rigetti's
simulator, the Quantum Virtual Machine (QVM) may be accessible
through the system programming interface (403). Users may simulate
all or parts of their algorithm with the QVM to test for errors
and/or expected behavior. The user may utilize checking and/or
debugging capabilities. For example: the interface may allow for
checking for compile time errors such as undefined variables and/or
operations; the interface may allow for checking of gate depth
constraints; the interface may allow for checking of conventional
hardware constraints such as recursion limits and/or potential
run-time errors; the interface may allow for debugger modes, which
may include for instance inspection of breakpoints and thread
execution state.
[0102] The algorithm may be compiled (503) through a system
programming interface (403). The compilation may include: a
translation of an algorithm to a set of machine executable
instructions, for instance a set of executable gates and readout
operations; translation of an algorithm and/or instructions to
another algorithm and/or instructions, for instance reducing the
number of gate operations required to approximately implement a
unitary to optimize the algorithms efficiency; providing
information about potential plaquettes available to perform the
algorithm, for instance their connectivity, and/or available
gate-set, and/or benchmarks; and providing information about other
compilations, for instance if a requested subroutine has been
compiled for use with a previous algorithm.
[0103] The plaquette resources required for an algorithm may be
determined (504) by the user and/or compiler at a system
programming interface (403), and/or by a scheduler (405). The
information used to determine resources may include information
stored, for instance in databases, as a few examples: information
about the properties of plaquettes may be stored in a device
database (411), and/or information about other execution requests
may be stored in a request database (404), and/or information about
resource availability may be stored in an execution job database
(408). A user may submit information that affects the requirements
for resources, for instance number of qubits and/or lattice type
and/or performance and/or specific plaquette configurations. A
multitude of constraints and objective functions may be provided to
a plaquette generator (406) that may determine optimized mappings
between resource/algorithm request and potential resources.
[0104] The execution of a specific computation may be requested
(505) on the system by the user through a system programming
interface (403). A requested execution job may be stored (506) by
the system, for instance by a database such as request DB
(404).
[0105] A requested execution job may be scheduled (507) by a
scheduler (405). The scheduler may make use of a plaquette
generator (406) to map multiple requests for resources into a
multitude of epochs. For example, it may be determined that two
jobs can be placed on the system concurrently (as one epoch) if
they are determined to be compatible with non-overlapping plaquette
resources. The Scheduler may access information about a multitude
of requests in the request database (404) and/or in the execution
job database (408) to determine schedules of epochs. The Scheduler
may access information about the availability of computational
resources, for instance by communication with a resource manager
(407). The Scheduler may update users, for instance through the
device database (411) and/or the request database (404) with
information regarding availability of resources and/or information
about the expected timing of a multitude of executions.
[0106] An execution job and/or an epoch of jobs may be stored in a
memory (508) such as job execution database (408), that may include
scheduling information. The execution job and/or epochs may be
stored in a queue or stack data type. The execution job and/or
epochs may be stored in a low latency memory cache, for instance
local to the control system.
[0107] A multitude of plaquettes of hybrid quantum-classical
resources may be prepared (509) for the execution of one or more
epochs of jobs, by, for instance, a resource manager (407) or an
execution engine (409). Information about the desired configuration
may be taken from the execution job database (408), for instance by
querying for the next epoch in a sorted queue or stack. The
resource manager (407) may indicate the availability of system
resources with respect to the current job and future schedules.
[0108] An epoch may be executed (510) on the system, for instance
using a multitude of QPU plaquettes (410). Results of a multitude
of executions and associated information may be returned (511), for
instance to a database such as a results database (412).
Meta-information about an execution job within an epoch, such as
user information, may determine how the results are stored by the
system, for instance memory location. Results may be post-processed
or otherwise analyzed by the system, for instance by a multitude of
QPU plaquettes (410) or the execution engine (409). Results may be
stored in the device database (411), for instance, if the results
are pertinent to benchmarks or otherwise understanding aspects
about the system and/or specific QPU plaquettes (410). A user may
be able to access results from executions, for instance the
execution they requested, through a system programming interface
(403).
[0109] A multitude of epochs may be executed to evaluate benchmarks
(512) or otherwise provide information about the system and/or
specific QPU plaquettes (410) intermittently. The execution
information about these epochs may include instructions and/or
analysis and/or information about recalibration. The execution
information about these epochs may be stored in a database such as
the execution job database (408) and/or they may be stored and/or
managed by a resource manager (407).
[0110] System information may be updated (513) as the result of new
information about the system, for instance in response to a change
of contents in the device database (411). Such updates may result
in changes to the system information interface (402).
[0111] An example control rack architecture 600 for full
virtualized hybrid classical quantum computing is shown in FIG. 6.
The control rack architecture 600 comprises user aapplications 601
(provided from the cloud, for example), control lines 602 (which
may be multiplexed), readout lines 603 (which may be multiplexed),
a hybrid control rack 610 and quantum hardware 620. The hybrid
control rack comprises classical control hardware 611 (such as
CPUs, GPUs, etc.), XY control spoolers 612, Z control spoolers 613,
coupling control spoolers 614, readout spoolers 615, (612-615 being
for waveform operations), DAC/Upconverters 616, and DACs 617. The
quantum hardware 620 comprises: qubits 621 and controllable
couplers 622.
[0112] The control system may include one or more of the following.
Hierarchical architecture within the control system, with
abstraction/virtualization within respective layers. Constrain
high-RAM allocations to larger qubit plaquettes. For each qubit,
one or more control signals is provided to realize 1Q, 2Q or nQ
gates, as well as a signal path to read the state of the qubit. The
control and readout signals for multiple qubits may be multiplexed,
such as RF multiplexing on a transmission line, or optical
multiplexing on a fiber. Each control signal is driven by a
waveform engine; the waveform engine takes parameters for a gate
signal (shape, amplitude, frequency, phase offset, start time) and
produces the commanded signals. Readout is accomplished by readout
engines consisting of a waveform engine for generating the
interrogation signal and an analysis engine for determining the
result of the qubit measurement.
[0113] Commands for the waveform and readout engines (612-617) are
provided by the classical compute functionality of the hybrid
classical/quantum processor 611 (the "sequencers"). Soft
processor(s) may be on the same FPGA as the waveform engine logic
and hard processor(s) may be integrated on the same die as the
FPGA/ASIC as the waveform engine. Processors are connected to the
waveform engine via a high-bandwidth, low-latency (very much less
than the coherence time) communications link/bus. Results from
readout engines are distributed to all sequencers that are
associated with a plaquette to enable hybrid computing. A mechanism
to determine the allocation of physical classical resources shared
between sequencers (i.e. RAM physically connected to a group of
sequencers). If a program requires more RAM, it may prevent other
programs to run on sequencers that share the same RAM resource, so
the user could be charged more to run that program. In some
embodiments there is a one-to-one mapping between sequencers and
gate signals, so these can be readily partitioned into
plaquettes.
[0114] Readout signals may be multiplexed, for example 8:1. Each
qubit readout is controlled by a single readout transmit sequencer
and a readout receive sequencer. The signals for eight transmit
sequencers, for example, can be added to be combined onto a single
readout line. The resulting received waveform is distributed to
each of the receive sequencers, each of which uses a matched filter
to separate out the readout result from the associated qubit, while
rejecting interference from any other readout operations which
might be being performed simultaneously. The size of a plaquette
could be set to be a multiple of the largest number of multiplexed
signals controlled by a single sequencer (in this example 8Q hence
plaquettes would be up to n*8Q). In this case, the plaquettes would
also be physically constrained to include qubits in corresponding
8Q chunks. For example, a plaquette of 15 qubits might span 3
octagons and hence require an allocation of 3 multiplexed readout
lines in this simple solution. Multiplexed readout or signal lines
could be serviced by multiple sequencers running separate programs.
Readout requests for (two) independent plaquettes that share a
multiplexed readout or gate signal can be staggered by the compiler
to avoid interference between programs running on the (two)
plaquettes. Readout by multiple sequencers would still need to be
coordinated by the compiler, or the compiler can allow simultaneous
multiplexed access if the specific readout/gate signals are known
(from characterization measurements) to not interfere with each
other significantly. A method can be provided to guarantee that
simultaneous multiplexed access does not occur; this might incur a
higher price for the user.
[0115] The hybrid classical quantum system can include a
low-latency means of communicating between sequencers, particularly
readout results. At compile time, the amount of low-latency traffic
generated by a program can be calculated and provides another
billable metric. In some implementations, if program A and program
B are running simultaneously, and program A requires a lot of
iSWAPs, program B may suffer increased latency waiting for the bus
to be available to transfer qubit measurement results. Guaranteed
latency metrics could be another billable item. In the preceding
example, if the user running program B is willing to pay for the
absolute lowest latency, the low-latency messages from program B
could be prioritized over the onslaught of messages from program
A.
[0116] A description of an example embodiment of a multiprocessor
for hybrid quantum-classical computing with virtualization support
in hardware is provided. The following describes how the task of
mapping hybrid quantum-classical programs (jobs) to available
hardware can be performed by the hardware itself using concepts
from classical computer virtualization.
[0117] As an example, if a user submits a program to be run on four
interconnected qubits, that program could start on four specific
qubits (call them q0-q3). During the course of execution, there
will be periods of time when the qubit states are not classical
(i.e in a superposition of states, or entangled), and periods after
the qubits states have been measured, and the states are all
classical. When the states are all classical, the virtualization
manager ("hypervisor") could decide to migrate the program to a set
of four other qubits (call them q10-q13), provided the connectivity
between the qubits is sufficient for the desired program. This
would allow programs to make efficient use of the classical and
quantum resources, by letting the hardware reallocate resources as
jobs are submitted.
[0118] There are two aspects of this approach which are carefully
considered. The first is that the state of each qubit ("clean":
classical 0, classical 1; or quantum indeterminant, "dirty" in the
language use below) is propagated throughout the system with low
latency. This allows the hypervisor to know which qubits are not
immediately in use and thus could potentially be reallocated. It
also allows any running program which might have control flow
operations that depend on the readout result of a qubit to have the
information necessary to execute that control flow. A simple,
specific, example of this would be using the readout result to
decide if a gate should be played to reset the state of a qubit.
This aspect is represented by the Qi state and hygiene mask
discussed below with reference to FIG. 9.
[0119] The second aspect is that the quantum gate instructions need
to be available with extremely low latency to all the individual
control processors for each qubit. Continuing with the example
above, if the users program performs a gate on a qubit, and that
gets allocated to q0 for one iteration, but then is reallocated to
q10 for another iteration, the control system for q10 needs to have
that instruction. This aspect is represented by the Qi unitary
command discussed in more detail below. The translation table
discussed below is what holds the current mapping of programs to
qubit resources. The programs are written to use "virtual" qubit
addresses, which this table then translates to physical qubits.
[0120] The description below encompasses a range of system scales,
from the case where all qubits could be controlled by a single
classical compute chip, so that the low-latency shared memory could
be implemented as a multi-port memory register, to cases where
communication between chips, boards, and chassis are needed. In
these later cases, tradeoffs between interconnect density and
latency are considered.
[0121] The hybrid-quantum supercomputer described below with
reference to FIGS. 7-14 is an example of a system of the present
invention according to some embodiments.
[0122] FIG. 7 is a representation of an example virtualizable
hybrid quantum-classical processor unit, and FIG. 8 is a
representation of an example of two coherent virtualizable hybrid
quantum-classical processor units. The processor units 700, 800
comprise: independent QPU cores 701, 801 where each box in the
figure corresponds to a thread of execution for an array of N
qubit(s); independent CPU cores 702, 802 where each box corresponds
to a classical thread of execution (which may be processing an
instance, doing minimum weight perfect matching, etc.); local Qache
buses 703, 803 which are tightly coupled memory shared between all
the QPU and CPU cores on their corresponding hybrid processing
units (HPUs); processor-to-processor (system) Qache buses 804, 904
which enable coherency of the hybrid shared cache across multiple
hybrid processing units; local Qache copies 705, 805, 905, which
are cache copies local to a given hybrid processing unit that is
managed by that hybrid processor's Quantum Memory Management Unit
(QMMU) and holds coherent copies of all hybrid classical variables
and state readout for the corresponding entire system; hybrid
virtualization managers (hypervisors) 706, 806, 906 which load and
manage jobs for execution, and part of managing these jobs includes
configuring and maintaining the QMMU; Qache Virtualization Modules
707, 807, 907 where the QMMU maintains cache coherence between the
local qache copy and the local qache copies of other hybrid
processors on the system qache bus. As such the hybrid processor
708, 808, 908 is a collection of concurrent quantum and classical
cores that can share memory and form a standalone-capable unit for
hybrid quantum computation. Note that the QPU cores 701, 801 are a
combination of a QUIL machine, microwave signal
generation/reception hardware, qubits, etc. as described below with
reference to FIG. 13.
[0123] The neighbor hybrid processor 809 is a second hybrid
processor that sits on a cache coherent bus with another hybrid
processor. Examples of arbitrary parceling 810 of hybrid resources,
which are arbitrary subsets of the available quantum and classical
cores from the hybrid multi-processor that form the work units for
execution of customer hybrid computation, are indicated in FIG. 8
for customers 1, 2 and 3 as 811, 812 and 813. All arbitrary subsets
maintain tight coupling through the shared memory interface (system
Qache bus).
[0124] The QMMU and the Qache are shown in detail in FIG. 9. The
QMMU and Qache operate with the following: Ci Classical Shared
Variable 921, which is a classical bitstring for communicating
state/sharing data between QPU and CPU cores; Qi Gate Command 922,
which are gate commands for triggering specified state manipulation
of qubits Qi from i=0 to i=N, where N is the number of qubits
allocated to that QPU core; Qi State 923, which is the last
measured state of Qi (if gate has been applied, this Qache entry is
marked dirty in the hygiene mask., if measured state is still
valid, hygiene mask holds clean for this Qache entry); Qi State
Hygiene Mask 924 indicates if quantum information exists in the
system for Qi or if Qi contains a bit of classical information. A
Coherency Agent 925 uses a cache coherence scheme (snooping,
directory based, etc.) to maintain Qache coherency across the
multiprocessor system.
[0125] A QMMU Bypass Bus 926 enables a calibration agent by
providing direct access to underlying physical qubit resources, and
also enables virtual migration within or between systems. The
hypervisor 906 has knowledge of qubit topology to process quantum
state swap (within the system) when the cache for a qubit state is
dirty and re-parcelling is requested. If the qache for the qubit
state is clean, the classical information itself can be shuffled
(within or outside system) and the freed qubit re-initialized.
[0126] Configurable Translation Table 927 enables virtual
"migration" within a system. Qubits can be retargeted system wide
by code in situ using this table, alleviating the need to
physically move the code around the system in order to
reparcel.
[0127] At compile time, user code can be targeted to specific
plaquettes, by querying the calibration database for the details of
each gate for a corresponding qubit in the plaquette and then
synthesizing binary programs consisting of schedules of primitives
such as waveforms, delays, phase changes, as well as explicit waits
for an operation to complete on another sequencer (communicated via
the "spoolnet" described below). In this case, deterministic
programs can be completely specified as a set of scheduled
operations with known durations. Alternatively, the user code can
be compiled to "relocatable" code that consists of gate operation
templates on virtual qubit targets. When the program is scheduled
to run on an allocated set of physical qubits, a lookup table is
generated mapping the low-level operations that make up the gate
operation template on virtual qubits to calibrated operations on
the corresponding physical qubits. As an example, a CZ gate on
virtual qubits 0 and 1 could result in the following gate operation
templates.
[0128] For the Z (flux) control on qubit 0 [0129] 1. WAIT for
"done" message from any XY operations on qubit 0 and qubit 1 to
complete. The origin and encoding of the "done" message to wait on
is obtained from the lookup table populated by the hypervisor.
[0130] 2. PLAY waveform at location 0. This location is reserved
for the calibrated CZ waveform for this gate [0131] 3. SEND message
"done" to all controls in this plaquette. The destination and
encoding of this "done" message is obtained from the lookup table
populated by the hypervisor.
[0132] For the XY (gate) control on qubit 0 [0133] 1. WAIT for
"done" message from Z controller [0134] 2. DELAY for calibrated
time stored in spooler reserved memory location "A" to effect any
RZ correction gate needed [0135] 3. Send "done" message to all
controls in this plaquette. The destination and encoding of this
"done" message is obtained from the lookup table populated by the
hypervisor.
[0136] For the XY (gate) control on qubit 1 [0137] 1. WAIT for
"done" message from Z controller [0138] 2. DELAY for calibrated
time stored in spooler reserved memory location "A" to effect any
RZ correction gate needed [0139] 3. Send "done" message to all
controls in this plaquette. The destination and encoding of this
"done" message is obtained from the lookup table populated by the
hypervisor.
[0140] At run time, the lookup tables would be initialized by the
hypervisor with the specific details required to target the
allocated physical qubits. These instructions then directly
populate the scheduling queues of the spooler associated with each
controller. See figure "details of a spooler." Each entry in the
scheduling queue has a timestamp or condition indicating when the
operation should be executed. The entries can include operations to
control oscillators, which could be implemented as numerically
controlled oscillators (NCOs) which track the frequency of the
qubit operation (i.e. the frequency of the f01 transition or of the
CZ02 flux pulse). The entries can also indicate which waveform
envelope should be played, as well as which oscillator should be
used to modulate the waveform to perform the desired gate
operation. The lookup tables could also be implemented by dynamic
signal routing between sequencers co-located on the same silicon
chip, physical board, or potentially between boards. This would
dramatically reduce the latency compared to sending messages over
an encoded or multiplexed bus.
[0141] Lower level physical instructions can also be provided as
part of the instruction set which bypass the QMMU lookup table
functionality to allow direct physical access to the qubit control
sequencers. This would provide a natural way to perform calibration
operations and system diagnostics. These lower level instructions
could be implemented by providing a single "mode" bit in the
op-code to distinguish user-level virtual instructions requiring
retargeting from lower level system instructions. These lower level
system instructions could also be restricted so that only certain
memory locations could execute them, as a means of improving system
security.
[0142] Arbitrary Qache bus topologies are supported and are limited
only by balancing 10 constraints with latency overhead
considerations. Here follows a variety of possible Qache Bus
topologies as the system scales to many hybrid processing units
(arbitrary resource parcelling not shown). A 4-processor coherent
system 1000 is shown in FIG. 10; the system comprises four HPUs
1001-1004. FIGS. 11 & 12 show an 8-processor system (HPUs
1101-1108, and HPUs 1201-1208, respectively) with two different
coherency topologies--fully connected and hypercube (1209),
respectively. The hypercube case could be generalized as connecting
the HPU via a network switch which could implement a number of
topologies internally--fully connected crossbar, hypercube,
hypertorus, etc. As the system scales past a fully connected graph,
the application model, 10 constraints, latency overhead, and
bandwidth limitations need to be traded off in the coherency
mechanism and topology employed (e.g., the speed of snoop based
protocols will be overcome by its bandwidth inefficiency, the 10
scalability of the hypercube will win out over the speed of the
fully connected graph, etc.).
[0143] A single user can be allocated resources across multiple HPU
units, and the resources within each HPU can be allocated among
many simultaneous user programs. At a finer level, multiple users
can run on subsets of qubits within each QPU unit, and the
classical portion of the program control can run on subsets of the
CPU cores available in each HPU.
[0144] The QMMU can parcel up, virtualize, and pool quantum IC's
(even across different fridges). This allows us to offer arbitrary
plaquette bundling w/ classical resources--cores can remote write
qubits through the Qache bus at a small and bounded latency cost
(one hop). This would allow any core to control not only any
physical qubit anywhere on the Quantum IC but even physical qubits
on remote IC's (provided the physical qubit has been mapped by the
hypervisor to the program's virtual address space and the
respective daughter cards are accessible over the same Qache Bus).
Therefore there is the flexibility of putting a "foreign system" on
the "ring" as in FIGS. 10-12 (where one of the HPUs may be the
foreign system).
[0145] Customers may want a mix of dedicated but interconnected
resources, as well as multi-tenant resources. For example, a
customer may prefer dedicated access to a physical system for
reasons including increased performance or more security. The
customer can generate a deployment policy that governs how the user
applications are deployed to the hardware. This deployment policy
would imply requirements on the underlying hardware, and thus could
be billed at different rates depending on the demand for the
hardware resources. Using the HPU memory-coherency schemes (i.e.
Qache) shown above, there are at least three inter-thread latency
classes: [0146] Level I: Local Qache latency (.about.10's ns)
[0147] Level II: System Qache Bus latency (.about.100's ns) [0148]
Level III: Networked latency (.about.<1 ms)
[0149] Intra-HPU thread latencies are always Level I by definition
because they share a local Qache. HPU's on the same System Qache
Bus are "Qache Connected" and have level II capable inter-thread
latency relationships between them. A level III inter-thread
relationship can be formed between any HPU's across the datacenter
since it is built from a conventional network connection.
[0150] When deploying an application on the HPU based services, the
following decisions need to be made, either automatically by the
compiler or other application, or by the user explicitly. First,
should the application be constrained to a dedicated set of
resources (to the exclusion of other users or applications) or can
it target virtualized hardware, and then be mapped to physical
hardware dynamically by the hypervisor? Second, various metrics
need to be specified: how many QPUs to use (perhaps to parallelize
the algorithm); how many interconnected qubits are needed in the
lattice for the algorithm to run on; and what classical compute
resources are needed (CPU cores, GPU cores, memory space, etc).
[0151] Second, given the results of the above decisions, what
latency class (described above) is needed? For programs that use
little to no control flow during the coherence time of the qubits,
the latency between qubit controls (spoolers) is of little concern,
whereas programs that rely on performing gates conditionally based
on the measurements of other qubits will have stringent latency
requirements. This will constrain the hypervisor when it allocates
the physical resources to run the program.
[0152] Third, the qubit lattices need to be decided. This includes
both the topology needed (what degree of interconnection is
available and what is most efficient for the algorithm), as well as
the qubit technology itself. The HPUs could support QPUs based on a
number of qubit technologies (i.e. superconducting qubits, spin
qubits, ion traps, etc), some of which may be more suited to a
particular algorithm than others.
[0153] Finally, the user can then run their application on a
quantum virtual machine, quantum simulator, (using classical
compute resources in the HPUs or in dedicated classical compute
hardware), and when desired, seamlessly migrate the application to
real qubits.
[0154] FIG. 13 shows an example system 1300 which comprises a
hybrid classical computer-quantum control system connected to a
four-qubit quantum IC. In this example two of the qubits, Q0 1301
and Q2 1303 have a fixed frequency, while Q1 1302 and Q3 1304 are
tunable via a magnetic flux provided by an additional digital to
analog converter channel (see channel with physical flux card 1322,
for example). The system is scalable to a much larger number of
qubits and with many more qubits controlled per control node. All
of the soft digital links shown in FIG. 13 belong to one bus (the
system Qache Bus). The Qache bus could be implemented between
chips--see hybrid Qache bus 1305, for example--with deterministic
low latency using communication protocols such as the GBT/Versatile
Link developed at CERN. (See
https://wiki.to.infn.it/lib/exe/fetch.php?media=elettronica:projects:cms_-
dt:gbtsystem:bar on-gbtfpgaug.pdf) There is a sideband bus that is
not shown here for the sake of simplicity (spoolnet), that is used
for timing synchronization and concurrency control.
[0155] In FIG. 13, the classical CPUs 1308 can have the same
industry-standard architecture as is used in general purpose data
centers. This would allow a user's program to run against a quantum
virtual machine (QVM) and then immediately target the real QPU,
without needing to recompile the software. This could happen after
a user is done prototyping hybrid algorithms on a QVM in the
traditional cloud infrastructure and then wants to run code on a
real Quantum IC.
[0156] In FIG. 13, the logic 1306 can be implemented as a standard
processor chip connected to a custom logic chip, which in turn
could be implemented as an FPGA or an ASIC. This connection could
be done inside a standard BGA package, or could be implemented as a
stacked multi-chip module. Alternatively, a single custom logic
chip could be used, either an FPGA with integrated hard-IP CPUs
(e.g. Intel Stratix with ARM CPUs) or as an FPGA with soft-IP CPUs.
The custom logic chip could also be an ASIC, with or without a
portion of reconfigurable logic for efficient implementation of
dynamic re-routing of the internal, on-chip communication busses
(Qache and spoolnet) described above. As an example, Intel produces
FPGAs with integrated cache coherent high bandwidth interconnects
(QPI and UPI) designed to interface with high performance Xeon
CPUs.
[0157] In the specific example shown in FIG. 13, the logic 1306 is
connected to DDR4 Random Access Memory (RAM) 1307, hybrid Qache bus
1305 for communication between chips, gate cards 1316 and readout
cards 1320. The logic 1306 comprises: an 80-thread CPU 1308
including hypervisor 1309; an Integrated Memory Controller (IMC)
1310 and cache 1311, a QMMU 1315 and a QUIL machine 1312 with
modules 1313, 1314 for handling logical gate/readout threads. The
IMC is the control logic needed to interface to DDR SDRAM
memory--the IMC 1310 would load data from DDR4 1307 into the cache
1311 to be used by the rest of the system. The QUIL machine
represents any processor or logic that is responsible for reading
machine instructions from memory and executing them against qubits,
for example the QUIL code gets compiled to binary machine
instructions which the QUIL machine reads from memory and executes,
thereby generating gates and readout instructions, and returning
results to memory to be used by other QUIL machines or the
classical CPU code. Physical gate cards 1316 are provided for each
qubit, where each gate card comprises a gate decoder 1317, a
spooler 1318 and an RF DAC 1319. Furthermore, physical flux cards
1322 are provided for each of the tunable qubits (Q1 & Q3),
where each gate card comprises a gate decoder, a spooler and an RF
DAC. Readout cards 1320 with ADCs 1321 are provided for pairs of
tunable and fixed qubits, for example Q0 & Q1 and Q2 &
Q3.
[0158] Each of the physical controls for the qubits can be
implemented as a "spooler" 1318 which is responsible for tracking
the phase of the associated control signals (using, for example, a
numerically controlled oscillator), and which produces modulated
waveform data for the digital to analog converters (DACs) 1319
which produce the analog signals to control the qubit. The spooler
may have a pre-loaded waveform library such that specific gate
signals can be generated by requesting a given waveform modulated
by a specified oscillator frequency and phase. All of these events
can be scheduled to occur at a specific time, or on reception of a
signal from another spooler or other part of the system. For qubit
state readout, the spooler works similarly, but performs a matched
filtering operation to determine the qubit state, instead of
modulating a gate control waveform.
[0159] During the migration, the hypervisor 1309 must configure the
QMMU 1315 to map the virtual resources specified in the program to
physical qubit resources. The Quantum Memory Management Unit (QMMU)
is a hardware accelerated virtualization module in the fabric of
the on-die integrated FPGA that is cache coherent with the many
hybrid programs running on that chip. The QMMU holds a global view
of the Physical Memory of the full hybrid system. It is able to
achieve this using an architecture similar to what can be found in
cache systems with many cores. Every QMMU in the hybrid system sits
on a very low and bounded latency ring (the System Qache Bus) and
broadcasts (i.e., for Qache Bus snooping) the following: bitstrings
of states resulting from measurement, dirty cache notifications
when the host box commands a quantum gate, and updates to shared
classical variables. A completely clean quantum state cache implies
all qubit states are known and no quantum information exists on the
system. At this time, the program state could be frozen and safely
swapped around the system. However, because the QMMU 1315 can be
dynamically reconfigured by the hypervisor 1309, the virtual to
physical mappings of the qubit resources can be modified in situ,
and the user's virtual resource allocation instance only need be
frozen and swapped if it is being completely removed from the
system.
[0160] Benefits of this architecture include: transparent user
virtual resource migration from QVM-capable to QPU-capable;
leverage state of the art compute tools by using industry-standard
CPU architectures (e.g. x86_64 or ARM); memory used by the quantum
program (e.g. a program written in QUIL) is natively available to
the CPUs on the system; QMMU virtualization supports arbitrary
plaquette bundling with classical resources; hypervisor and QMMU
enables a mixed-tenant model with rapid reallocation of resources;
architecture scales to many qubit control cards per chassis, and
many chassis per coherent system; latency of a single link is
almost same order of magnitude as signal propagation delay, (of
order 10's of nanoseconds); there is hardware support for
multi-threaded quantum programs; and Global Hybrid Memory
aggregated (broadcasts on Qache Bus are bus snooped) and
virtualized by the QMMU.
[0161] A method 1400 for QUIL Concurrency Control is described with
reference to FIG. 14 for enforcing execution ordering between the
sequencers controlling different qubits. QUIL machine 1401
comprises thread generation modules 1402 and 1403 for qubit 0 and
qubit 1, respectively. Instructions for the generation of an H gate
and the sending of a timestamp m1 are generated by module 1402 for
application to qubit 0. The instructions are sent over the Qache
Bus 1404 to the spooler 1406 for qubit 0. Instructions for the
generation of a CNOT gate with qubits 0 and 1, after receipt of
timestamp m1 are generated by module 1403 for application to qubit
1. The instructions are sent over the Qache Bus 1404 to the spooler
1407 for qubit 1. Execution of the instructions at spooler 1406
results in the formation of an H gate on qubit 0 and the "m1"
timestamp being broadcast over the spoolnet 1405 from the spooler
1406 for qubit 0 to the spooler 1407 for qubit 1 and other spoolers
1408 for other qubits. Receipt of the m1 message at spooler 1407
for qubit 1 results in the formation of the CNOT gate with qubits 0
and 1. By sending these messages on different ("out of band")
connections 1405 (referred to here as Spoolnet) than the Qache bus
1404, the latency of these concurrency messages can be guaranteed
without impacting the performance of the Qache bus.
[0162] Spoolnet 1405 distributes sub-nanosecond resolution timing
and allows QUIL thread synchronization to be implemented downstream
from the QUIL machine 1401, thereby allowing higher level
synchronization objects (i.e., no explicit notion of time, only
synchronization primitives) to be used at the QUIL Machine level.
These primitives are embedded in the QUIL instructions as a tag and
require no QUIL Machine clock cycle overhead, yet provide maximum
latency performance in enforcing inter-qubit gate dependencies
between threads.
[0163] This scheme for concurrency control has many benefits
including: guarantees satisfaction of gate dependencies; no need
for dedicated clock trees; abstracts timing from QUIL machine by
implementing QUIL synchronization primitives; deterministic,
sub-nanosecond timing can be accomplished over standard computer
data connections like Ethernet by using techniques similar to those
developed as part of the White Rabbit protocol (see
https://white-rabbit.web.cern.ch/); Out of Band traffic preserves
tight/predictable latencies on Qache Bus 1404 and Spoolnet
1405.
[0164] In summary, for some embodiments of the coherent
virtualizable hybrid quantum-classical processor system described
above with reference to FIGS. 7-14 one or more of the following
advantages can be achieved. First, each qubit control signal is
independently controlled by a thread of computation (implemented by
a CPU scheduling operations on the spooler). These threads are
synchronized, either with explicit signals, or through
deterministic timing. This makes it very natural to allocate a
collection of control threads (i.e. those associated with a
specific subset of qubits) to each user to natively support
multi-tenancy. Second, by implementing these independent control
threads with an industry standard CPU architecture, the same
computer hardware is used for both the classical computations of
the hybrid program, as well as for executing the quantum gates.
Thus, there is less of a boundary between the classical part of the
program and the quantum part. As an example, instead of having a
QUIL program running on specialized arbitrary waveform generator
hardware, waiting for gate parameters from a standard computer
which is running a classical optimizer, we have the optimizer
running on a CPU and when a quantum result is needed, the same code
on the same CPU executes the necessary quantum instructions, and
the qubit results appear directly in the memory space of the same
CPU so that the optimizer can continue operation immediately.
[0165] Systems and methods for matching orders within a demand
queue to a set of dynamically provisioned quantum-classical
instances, and allocating such instances to particular jobs/users
are described as follows. A system is described that, each epoch,
takes as input both the order book (demand queue) and the physical
system capabilities (the available quantum-classical
instances/plaquettes) and provides a partitioned and provisioned
system for the duration of that epoch. This system may also receive
as input the performance and quality metrics of the qubits and
other system characteristics. A connected set of qubits on a
quantum IC is referred to herein as a "plaquette", which may also
be described as a configuration of qubits and qubit-qubit links on
one or more quantum computation devices. An "epoch" is defined
herein as the period of time during which a physical
quantum-classical hybrid computing system is provisioned in a
particular fixed configuration; the epoch time may be on the order
of hours, or minutes, or in embodiments seconds or fractions of a
second.
[0166] Methods of determining the price of plaquettes sold on a
hybrid quantum-classical computer system are varied and different
approaches may be suitable for different circumstances. The minimum
unit of time for utilizing a plaquette on a QPU that may be
purchased is most conveniently a single epoch, or in some
embodiments, multiple epochs. Furthermore, a user will often want
to start use at a specified time or at least within a specified
time window. Prices for specific qubits or groups of qubits from
amongst a QPU chip full of qubits may be varied depending on
factors such as fidelity of qubits and groups of qubits. In some
embodiments a hybrid quantum-classical computer system may
autonomously sample and measure its own fidelity and use those
fidelities as an input to one or more of: a) order matching; b)
plaquette decomposition of the full chip; c) pricing of plaquettes.
Furthermore, plaquettes that remove the possibility for large
adjacent plaquettes on a chip may be priced at a premium.
[0167] When one doesn't know a priori what QPU time is worth, a
customer's application/request is going to inform this, and auction
types of pricing models may be effective. For example, a second
price auction may be used where the winner of the auction is the
second highest price offered. An auction system can comprise
multiple rounds of bidding, although multiple bidding rounds might
not always be directly compatible with a real-time
bidding/scheduling process. The auction process can sell specific
future epochs on the qubits of a QPU. One round of the concrete
auction system could look as follows: users submit collection of
bids for epochs on plaquettes; auction backend greedily produces
several alternative plaquette schedules potentially combining
several bids that can run concurrently to maximize the revenue of
such a bid combination and usage of the QPU; and the second most
valuable bid combination wins the round. In addition to selling
fixed future scheduled qubits in some embodiments one can also
always keep part of the QPU free to accept high priority jobs in
real time based on a single round bidding process.
[0168] An example computing system that assigns prices to different
qubit regions on a quantum processor may take input from one or
more of the following sources: a long-term database of design
characteristics of the device (e.g., qubit count, qubit
connectivity); a short-term database of measurements pertaining to
the physical characteristics of the device (e.g., one-qubit,
qubit-qubit interaction, readout fidelities, gate fidelity, native
gate availability, qubit count, link count, link topology,
coherence time, relaxation time, etc.); inferred characteristics
pertaining to the expressiveness of the device (e.g., instruction
availability); a database of user requests (e.g., system-wide
strain, historical usage patterns); and the particular
characteristics of a given user's request (e.g., urgency or
expected duration). This information can be retrieved from remote
stores via network communication, from remote agents via network
communication, from local caches. The system may be configured to
assign prices to plaquettes based on one or more of: their physical
characteristics; response to user demand; historical popularity;
and immediacy.
[0169] The system may be configured to automatically assess the
physical characteristics of a quantum device for input to a pricing
model. The system may assign prices to plaquettes through a
(multiple-round) pricing auction. Furthermore, a process may be
implemented that validates plaquette fidelity immediately before
user residence begins.
[0170] In some instances, a method for calculating a price for use
of a configuration of qubits and qubit-qubit links on one or more
quantum processor units by a user for running a computer program,
may comprise: accessing a first database by a computer processor
unit to collect design characteristics of the one or more quantum
processor units, including inferred characteristics pertaining to
the expressiveness of the one or more quantum processor units,
wherein the inferred characteristics include instruction
availability; accessing a second database by the computer processor
unit to collect measurements of physical characteristics of the one
or more quantum processor units; accessing a third database by the
computer processor unit to collect characteristics of a specific
user's request; and determining the price using data collected from
the first, second and third databases.
[0171] In some instances, a computer system for calculating a price
for use of a configuration of qubits and qubit-qubit links on one
or more quantum processor units by a user for running a program,
may comprise: a first database for storing design characteristics
of the one or more quantum processor units, including inferred
characteristics pertaining to the expressiveness of the device,
wherein the inferred characteristics include instruction
availability; a second database for storing measurements of
physical characteristics of the one or more quantum processor
units; a third database for storing characteristics of a specific
user's request; and a computer processor unit for determining the
price, wherein the computer processor unit is linked to the first,
second and third databases for accessing input data for the
determining.
[0172] An embodiment of a long-term ordering matching system 1500
is shown in FIG. 15. The system comprises a user space 1501, a
computer sub-system 1502 for running an order accepting process,
and other order process components 1503. Users 1501 submit bids
(via a web interface, via a web API, .etc.) on desired order
configurations, which may include: a particular segment of time
(e.g., 9 am-5 pm on Jul. 2, 2018), a particular duration (e.g., one
hour), and/or a minimum duration (e.g., at least one hour); a
particular subset of qubits (e.g., qubits 0-5), a particular
configuration of qubit connectivities (e.g., a T-shaped
configuration of four qubits), or a particular quantity of qubits
(e.g., any four qubits); a lower bound on qubit quality (e.g.,
minimum readout fidelity of at least 95%); as well as other
qualities.
[0173] The orders are processed by a filter 1505 which may be
configured to reject orders unless they satisfy certain criteria,
so as to constrain the auction. Such criteria may include: a
minimum plaquette size (e.g., at least 8 qubits requested),
sufficiently distant start time (e.g., no sooner than three days
after the end of the auction), a maximum duration (e.g., no longer
than one day), as well as other qualities. One or more of these
criteria may be chosen to simplify the packing process (e.g.
partitioning of the QPU chip into plaquettes) as follows: larger
orders admit fewer possible configurations; separating the start
times for the orders of large and small qubit counts ensure that
only large qubit count orders initially need to be packed; a
limited duration makes resource exclusion less likely; and so on.
Different order filling processes may generate different constraint
sets.
[0174] Bids (both the offered value and the configuration data as
specified above, as shown in the example order configuration 1507)
are captured in an order database 1506, where they collect. After
some interval of time passes (e.g., the duration of time available
to bidders in the auction divided by the number of rounds in the
auction, so as not to keep the auction horizon a fixed distance
away), a background process running on module 1509 locks the order
database, disallowing any more orders to be placed.
[0175] An order filling process then activates, calculating several
possible ways that non-conflicting orders could be filled. One such
filling is then selected according to some metric (e.g., the nth
most revenue-maximizing possibility) by module 1510. A bidding
round counter 1512 is decremented and the bidding process is
repeated if the round counter is not at zero. If the counter is
zero, the order filling selection from the previous step is sent by
module 1513 to the scheduler database 1514 as the plan of record,
and the counter 1512 is reset to the number of rounds in the next
auction. In both cases, the users participating in the bidding
process are informed of the results by module 1511. The order
database 1506 is cleared and unlocked and is kept unlocked by
module 1508 until the bidding is halted.
[0176] In some instances, a method of auctioning quantum computing
resources, may comprise: opening an auction and receiving price
bids electronically submitted by users, each price bid having an
order with a user desired qubit configuration, each order including
a number of qubits, a configuration of qubit connectivities, a
lower bound on qubit quality and one or more of a duration, a
particular segment of time and a minimum duration; rejecting a
specific price bid of the price bids unless the specific price bid
satisfies a criteria, the criteria including one or more of: a
minimum number of qubits and qubit-qubit links on one or more
quantum processor units, a start time of at least a fixed time in
the future, and a maximum duration; on satisfaction of one or more
specific criteria, closing the auction to any new price bids;
activating an order filling process, the order filling process
including calculating a plurality of solutions for filling
non-conflicting orders, and selecting one of the plurality of
solutions according to a metric; and informing users of a status of
their price bids. Furthermore, computer systems may be configured
to auction quantum computing resources as described above.
[0177] Determining plaquette resources needed for a program, with a
quality estimate of the resources, can be done while preserving
customer security and an agreement that the service provider won't
inspect the semantics of their programs or how they're using their
data--this can be achieved by anonymizing a program. For example,
stripping the gate descriptions, except for some basic properties,
in some embodiments including one or more of: what resources an
instruction acts on; whether an instruction performs a measurement;
an estimate of the number of times a given instruction might be
executed; and a desired list of native instructions.
[0178] Comparing a program against a list of available plaquettes
to find a good match may include, in some embodiments, one or more
of: matching high-activity program links with high-fidelity QPU
links; matching program topology (after restricting to
high-activity links, for cases where the problem is made easier)
with native QPU topology; and matching program qubit count with QPU
qubit count.
[0179] See the flow chart in FIG. 16 for an example of some
embodiments. A user 1603 sends one or more quantum programs 1604 to
a locally (in a user computer space 1601) running anonymizer 1605.
The anonymizer removes distinguishing characteristics of the
quantum program, then returns the anonymized quantum program(s) to
the user. Examples of anonymization techniques include: removing
gate parameters, removing gate names, permuting gates, removing
control structures (perhaps retaining expected execution count for
each instruction), removing all instructions and retaining only the
expected gate set, as well as others. The user then submits the
anonymized program(s) 1606 to an adviser 1607, which may reside on
a remote server 1602 (e.g., one owned and operated by the service
provider) or which may also reside on the user's machine. The
adviser retrieves a list of available plaquettes, together with
their operating characteristics from database 1609. (The precise
transmission mechanism here depends on the residence of the
adviser.) Operating characteristics may include one or more of:
qubit counts, qubit connectivities, native gate sets, fidelity-type
measurements of native gates, readout fidelity, relaxation or
coherence time (T1 or T2) measurements, randomized benchmarking
results, run quality of certain standard programs, historical
drifts, coherent and incoherent noise channel measurements, as well
as others. This retrieved data may contain information about all
quantum devices or about just some; and it may contain information
about all sub-plaquettes that could be leased on this device or
about just those plaquettes which are available to be leased within
some time window. The adviser 1607 then applies a combination of
heuristics to judge the appropriateness of each plaquette for
program execution, and provides scores for each plaquette. The set
of heuristics might include matching native gate sets, matching
plaquette and desired topologies, meeting fidelity requirements,
meeting coherence time or relaxation time requirements, as well as
others. Finally, the adviser returns these scores per plaquette
1608 to the user 1603.
[0180] In some embodiments, the adviser, which may be a
computationally expensive service, can run on a remote server or on
the user's local machine. If the adviser service runs on a remote
machine, the user might first anonymize their program contents
while preserving the salient operating characteristics. In both
cases, the adviser service retrieves a list of available plaquettes
and their operating characteristics from the service providers data
servers. This data may contain information about all of the service
provider's quantum devices or about just some; and it may contain
information about all sub-plaquettes that could be leased on this
device or about just those plaquettes which are available to be
leased within some time window.
[0181] An example system according to some embodiments may be a
system that marries quantum programs to potential plaquette
venues.
[0182] An example process according to some embodiments may be a
process that comprises one or more of the following: anonymizes
quantum programs by erasing identifying characteristics; anonymizes
quantum programs for structural analysis by third parties; combines
the structural analyses of several quantum programs into a single
collection of desiderata; compares the structure of one or more
quantum programs with the structure of a quantum execution target
and execution fidelity; compares the structure of a quantum program
with the structure of a quantum execution target and estimates
transfer faithfulness; compares the structure of a quantum program
with the fidelity properties of a quantum execution target and
estimates overall decrease in quality. Herein an identifying
characteristic of a quantum program may include the names of gates,
the parameters of gates, the ordering of gates, etc.
[0183] In some instances, a method of matching quantum computing
programs to particular subsets of qubits on one or more quantum
processor units, may comprise: receiving a quantum computing
program by an anonymizer unit, the anonymizer unit processing the
quantum computing program to remove distinguishing characteristics
to provide an anonymized quantum computing program; extracting by
an adviser unit of a basic structure of the anonymized quantum
computing program, the basic structure including qubit count, qubit
connectivity and minimum relaxation or coherence times for qubits;
comparing by the adviser unit the basic structure of the anonymized
quantum computing program with structures of a plurality of quantum
execution targets on the one or more quantum processor units,
wherein the plurality of quantum execution targets are subsets of
qubits and qubit-qubit links on one or more quantum processor
units, and determining appropriate quantum execution targets using
a heuristic, the heuristic including one or more of: matching
native gate sets, matching plaquette and desired topologies,
meeting gate activation fidelity requirements, meeting read-out
fidelity requirements, and meeting coherence time or relaxation
time requirements; and generating by the adviser unit of output
identifying recommended quantum execution targets for the quantum
computing program.
[0184] In some instances, a computer system for matching quantum
computing programs to particular subsets of qubits on one or more
quantum processor units, may comprise: (1) an anonymizer unit for:
receiving a quantum computing program by the anonymizer unit, the
anonymizer unit processing the quantum computing program to remove
distinguishing characteristics of a quantum computing program for
anonymizing the quantum computing program; and (2) an adviser for:
extracting a basic structure of the anonymized quantum computing
program, the basic structure including one or more of qubit count,
qubit connectivity, native gate sets, fidelity-type measurements of
native gates, readout fidelity, execution fidelity, relaxation or
coherence time measurements, randomized benchmarking results, run
quality of certain standard programs, historical quantum processor
unit performance drifts, and coherent and incoherent noise channel
measurements; comparing the basic structure of the anonymized
quantum computing program with structures of a plurality of quantum
execution targets, wherein the quantum execution targets are
subsets of qubits and qubit-qubit links on one or more quantum
computational devices, and determining appropriate quantum
execution targets using a heuristic, the heuristic including one or
more of: matching native gate sets, matching plaquette and desired
topologies, meeting fidelity requirements, and meeting coherence
time or relaxation time requirements; and generating output
identifying recommended quantum execution targets for the quantum
computing program.
[0185] In some embodiments there is some kind of matching between
an order book (whose rows consist of a user, a program, a qubit
configuration--which consists of both a topology and fidelity
requirements--and in some embodiments a time limit) and the
available sub-plaquettes of a partially-utilized QPU. Furthermore,
in some embodiments users pay more and get priority in the matching
process; and in other embodiments the process is optimized for
revenue, and accordingly schedules more resource-intensive jobs
(which can be priced more highly) more aggressively. In some
embodiments, particular plaquette configurations (which can be
based on previous experience that a particular configuration is
useful) can be preserved rather than allowing them to be split up
into less useful configurations.
[0186] FIG. 17 shows a representation 1700 of a 16 qubit QPU 1701
with changing plaquette configurations over 4 subsequent epochs
1702 (t=0, 1, 2, 3) where individual qubits are grouped into a
plaquette for each epoch (filled circles 1703). Plaquettes can
generally persist for several epochs (vertical dashed lines) and
may be separated by unused and inactive qubits (open circles 1704)
to prevent or reduce cross talk or entanglement between
plaquettes.
[0187] Process 1800 for combining plaquettes on an array of
plaquettes is represented in FIG. 18, where individually requested
plaquettes are combined to larger and more regularly shaped (e.g.,
convex with near minimal circumference) subgraphs, with reserved
unused and inactive qubits for crosstalk reduction, etc. as
discussed above. The graph of 2-qubit gates naturally provides a
criterion for how such a boundary should be defined. For example,
one could require that when removing the boundary unused qubits
from the 2-qubit graph, the graph components corresponding to
different plaquettes must be disconnected, i.e., no path exists
that originates in one plaquette and ends in another. A different
way of defining which qubits must be unused and inactive could be
by using an empirically calibrated matrix of qubit-qubit
cross-talk, i.e, a matrix (S_jk) where j and k are labels for
qubits on the device which specifies the strength (e.g., in
decibels or some other relevant unit) of cross-talk between qubits
j and k. In this case the requirement could be to disallow any
qubits labeled j, k from different plaquettes to have S_jk larger
than some threshold. Combined plaquette blocks can be merged to
form ever larger tiles. For example, plaquettes 1801 and 1802 can
be combined, with unused qubits 1806 (open circles) between the
plaquettes, forming a first combined plaquette block 1803. The
first combined plaquette block 1803 can then be combined with a
plaquette block 1804, again with unused qubits between adjacent
plaquettes, to form a second combined plaquette block 1805.
[0188] FIG. 19 shows a method 1900, according to some embodiments,
to preprocess a list of plaquette requests 1901 by combining
requests for plaquettes below a certain size (number of qubit)
threshold. For example, there may be a very large number of
requests for single and two qubit plaquettes. These should
generally be easy to allocate, but any part of the allocation
procedure that scales strongly with the total number of requests
may be slowed down by the need to handle all these simple requests.
By fusing several small requests into a larger request may make the
process more efficient. This may reduce the complexity of the
subsequent allocation/scheduling step. Specifically, a list of
incoming plaquette requests 1903 may be sorted 1902 by one or more
of their priority, the effective revenue per qubit and their
necessary number of qubits. In a subsequent loop, all requests with
number of qubits below some minimal number X, e.g., X=2 or X=10,
(see 1904) are successively fused with other requests (see 1905)
into a single effective request which now contains more qubits than
X. Finally, the list which now only contains requests above a
certain size is submitted for further processing (see 1906).
[0189] In some instances, a method of plaquette fusion, wherein a
plaquette is a configuration of qubits and qubit-qubit links on one
or more quantum processor units, may comprise: receiving by a
computer processor unit a plurality of plaquette requests; sorting
by the computer processor unit the plaquette requests by plaquette
qubit count; fusing by the computer processor unit the plaquette
requests with plaquette qubit count below a predetermined integer
value, X, into one or more fused plaquette requests; and submitting
a request list to an allocation process, wherein the request list
includes the one or more fused plaquette requests and unfused
plaquette requests. Furthermore, computer systems may be configured
to fuse plaquettes as described above.
[0190] FIG. 20 shows a method 2000, according to some embodiments,
for sorting plaquette requests 2001. Plaquette request list 2003
from the order book is sorted by one or more of: priority, cost per
qubit and/or number of qubits (see 2002). An empty allocation 2005
of plaquettes for the QPU is created (see 2004) and is subsequently
filled in a loop (see 2006-2009): starting from the highest
priority, highest revenue requests, the QPU is greedily allocated
until no more requests exist that can be allocated. Finally, the
complete allocation for one epoch is submitted (see 2009). The loop
may comprise: determining by the computer processor unit if there
are any unassigned qubits in the allocation (see 2006) and (a) if
there are no unassigned qubits then submit the QPU allocation for
the next available epoch (see 2009), (b) if there are unassigned
qubits then further determine if there are any unassigned requests
that fit onto the unassigned qubits (see 2007) and (i) if no
unassigned requests fit then submit the QPU allocation for the next
available epoch (see 2009), (ii) if unassigned requests fit then
add the highest priority remaining request to the allocation,
update the QPU allocation and the request list, and repeat the
determining (go back to 2006).
[0191] In some embodiments, a method of plaquette allocation,
wherein a plaquette is a configuration of qubits and qubit-qubit
links on one or more quantum processor units, may comprise:
receiving by a computer processor unit a plurality of plaquette
requests; sorting by the computer processor unit requests by one or
more of highest priority, highest revenue per qubit, and highest
number of qubits; initializing by the computer processor unit an
empty quantum processor unit (QPU) allocation; adding by the
computer processor unit the highest priority plaquette request to
the allocation; and determining by the computer processor unit if
there are any unassigned qubits in the allocation and (a) if there
are no unassigned qubits then submit the QPU allocation for the
next available epoch, (b) if there are unassigned qubits then
further determine if there are any unassigned requests that fit
onto the unassigned qubits and (i) if no unassigned requests fit
then submit the QPU allocation for the next available epoch, (ii)
if unassigned requests fit then add highest priority remaining
request to the allocation and repeat the determining. Furthermore,
computer systems may be configured to allocate plaquettes as
described above.
[0192] In further embodiments, a computing process for allocating
quantum computing resources to specific resource requests as
described herein, may further include one or more of: wherein each
resource request and allocation may be for a specific period of
time as measured in epochs; wherein an allocation may be specified
by providing the epoch, by listing the exact qubit addresses on the
QPU for each plaquette and assigning each plaquette to a specific
resource request; wherein a resource request may specify a user id
that is granted exclusive access to the quantum computing resources
during the scheduled epoch; wherein the plaquette allocation for a
single epoch may be stored in a computer memory and/or on a hard
disk, e.g., within a database; and wherein resource requests can
originate from different users, where they can have been submitted
at different times and they are self-contained.
[0193] A computing process for allocating quantum computing
resources to specific resource requests as described herein, may
further include one or more of: selecting a simultaneously
allocable request subset in such a way that it exactly or
approximately maximizes revenue; ensuring that request priorities
are respected; allocating resources in a round robin fashion across
some category of users that submit requests, where the category is
defined by a user priority, and/or where the category is defined by
a pricing tier; allocating resources based on an auction process
with multiple rounds of bidding; applying a heuristic to allocate
and schedule user access to qubits on a quantum processor;
scheduling a heuristic that operates by hierarchically combining
requests for qubit plaquettes of comparable size in order to make
the scheduling problem tractable by allocating larger segments of
the quantum processor at once, where requested plaquettes can be
grouped by their size and connectivity (very small plaquettes are
then combined into larger super-plaquettes with ideally very simple
shapes--e.g. rectangular--that are subsequently easier to tile the
full QPU with; scheduling and partitioning qubits on a quantum
processor such that cross-talk from simultaneously executed
programs on nearby plaquettes is minimized; scheduling and
partitioning that minimizes cross-talk by separating allocated
plaquettes by non-allocated qubits (when embedding/allocating
requested plaquettes into the QPU connectivity graph one can mark a
layer of immediately surrounding "buffer" qubits from being
allocated in subsequent embeddings), where the control system for
"buffer" qubits may in instances just be idle for the duration of
the scheduled epoch.
[0194] A computing process for allocating quantum computing
resources to specific resource requests as described herein, may
further include: combining individually requested plaquettes into
larger and more regularly shaped (e.g., convex with near minimal
circumference) subgraphs, with reserved "dead" qubits for
cross-talk reduction. The graph of 2-qubit gates naturally provides
a criterion for how such a boundary could be defined. For example,
one could require that when removing the boundary "dead" qubits
from the 2-qubit graph, the graph components corresponding to
different plaquettes must be disconnected, i.e., no path exists
that originates in one plaquette and ends in another. A different
way of defining which qubits must be dead could be by using an
empirically calibrated matrix of qubit-qubit cross-talk, i.e, a
matrix (S_jk) where j and k are labels for qubits on the device
which specifies the strength (e.g., in decibels or some other
relevant unit) of cross-talk between qubit j and k. In this case
the requirement could be to disallow any qubits labeled j, k from
different plaquettes to have S_jk larger than some threshold.
[0195] A computing system for allocating quantum computing
resources to specific resource requests as described herein, may
further include one or more of: a scheduling system that schedules
repartitionable connected resources over several time epochs; a
scheduling system that minimizes repartitioning overhead associated
with scheduling connected resources over several time epochs by
stacking requests for similarly sized plaquettes along the time
(epoch) axis (i.e., it allocates the same plaquettes to these
requests but at different times), wherein the qubit connectivity
graph is a graph with all qubits of a QPU as nodes and an edge for
every available 2-qubit gate.
[0196] It is noted that: a single epoch QPU allocation is given by
a specification of non-intersecting plaquettes where each plaquette
is assigned to a particular user; and a resource request specifies
a minimum number of qubits, a minimum degree of connectivity (or
alternatively a specific required connectivity graph), a required
level of average quality (gate fidelity, coherence time), a
required number of epochs and the price or a range of prices that
the user has agreed to pay.
[0197] In some embodiments there may be different types of prepaid
credits. In some embodiments, a "bin filling" mechanism is used
where the available plaquettes are "bronze" plaquettes, a few
"silver" plaquettes, and a couple of "gold" ones, which are
statically determined blocks, "gold" being the highest value
blocks. Other names may be used for the categories, preferably ones
that are clearly of different perceived values--for example, one
could also use "silver", "gold" and "platinum" categories, where
platinum is the highest value. (Value may be determined based on
fidelity of qubits, fidelity of gates, connectivity, etc.)
[0198] Systems and methods for reservation, purchasing, metering,
and billing for virtualized quantum-classical computing are
considered in further detail. Here the focus is on the direct user
interaction with the system in order to achieve any one or more of:
a) viewing the available plaquettes and instances and types
thereof; b) viewing pricing information for plaquette reservations;
c) reserving plaquettes and quantum-classical instances; d) viewing
current accumulated bill and historic usage; and e) purchasing
credits to be applied to an user's account balance; etc. Such a web
interface may be configured for viewing available plaquettes and/or
placing orders (for example, making calendar reservations for a
plaquette for a number of epochs to run a user program). This web
interface may in embodiments be the user interfaces 202, 203 of
FIG. 2, the user interface 301 of FIG. 3 or the user interface 401
of FIG. 4, for example. In some embodiments, the available
plaquette information is provided for the web interface by a system
that queries the plaquette analysis module (see FIG. 2 and related
discussion, or other relevant databases discussed herein). The
viewing available plaquettes may include displaying quantum
processor types, embeddable plaquettes, numbers of qubits,
topologies, qubit quality, availability in real time, etc. The
system could also display real time price information, and an
option to view historic price information and historic use and
performance statistics of a selected qubit, again available in a
database such as described herein.
[0199] Reservation systems may be configured to: enable users to
select custom instances; to provide automated resource allocation;
or otherwise. Some example configurations are provided below.
[0200] In some embodiments a reservation system may be configured
as a custom instance plaquette rental system. The system displays
available plaquette and qubit resources to the user on a graphical
user interface (GUI), for example. The system may be configured to
sort the available resources into one or more of the following
categories: available QPU resources by device type, embeddable
plaquettes, number of qubits, plaquette topology, qubit quality,
etc., to help users quickly find the information and qubit
configuration they need. The system can have one or more of the
following input fields with the option to choose different
resources with options such as listed: rental type input field,
with options of part plaquette or whole plaquette; qubit
connectivity pattern, with options of linear, ring, fully
connected, star, custom (which may be a locked option only
available to certain users), etc.; device type input field, with
options of annealers, fixed tunable qubits, fluxonium qubits, ion
trap qubits, etc.; availability of resources, with options of
percent of time allocated, calendar time, etc.; booking type, with
options of specified time starting now, specify start time and
duration, etc.; overall resource priority, with options of cost,
performance or quality, and sub-options of low, medium, high,
emergency, etc.; and classical resource priority, with options of
memory, CPU, or balanced memory and CPU.
[0201] In some embodiments a reservation system may be configured
as an automatic configuration plaquette rental system. The system
prompts a user to upload code that the user wishes to run so that
the code may be analyzed by the system to determine a basic level
of resource requirements to enable the code to be run. (Note that
this step may in some embodiments be run anonymously as described
above with reference to FIG. 16, for example.) The system requests
input from the user regarding: desired fidelity, with options of
different ranges of fidelity which ranges may be classified for
example as silver, gold or platinum where platinum is the best; and
priority, with options of low, medium, high or emergency, for
example, where the categories increase in price with the level of
urgency and the higher priced options will provide the user with
access at or above their requested fidelity sooner. The system then
parses the uploaded code and returns to the user recommendations on
suitable resources, including one or more of: a qubit connectivity
pattern, which may be linear, ring, fully connected, star, custom
(which may be available only to select users), etc.; quantum
processor types, which may be annealers, fixed tunable qubits,
fluxonium qubits, ion traps, etc.; availability of resources, which
may be percent of time allocated, calendar booking, etc.; booking
type, which may be by specified time starting now, specified start
time and duration, etc.; overall resource priority, which may be
cost, performance or quality based, and further categorized as one
of low, medium, high, emergency, etc.; and classical resource
priority, which may be memory, CPU, or balanced memory and CPU.
After recommendations are provided to the user, the system may
offer the user limited customization (or fine tuning) of fidelity,
for example, or other advanced features.
[0202] Some examples of graphic user interfaces for web-based
systems for the presentation, reservation, and provisioning of
individual qubits or sets of qubits from a larger quantum computing
system or chip, to a particular user are shown in FIGS. 21-26.
[0203] These web-based systems may be used for the configuration of
virtualized quantum resources and classical co-processing resources
to meet user requirements. Furthermore, these web-based systems may
be used for the visualization of quantum machine images (a
virtualized programming and execution environment designed for
users to develop and run quantum software applications) and
resource loading of particular qubits/plaquettes.
[0204] FIGS. 21-24 are a series of user interactive screens that
can in some embodiments be used to provide the user the ability to
select options for a custom plaquette rental. For example, starting
with the GUI 2100 of FIG. 21, a user is able to choose the type of
QPU or "device" 2101 on which the user wants to rent a plaquette.
The user can select, by clicking or otherwise, a device type from
the menu 2102, which includes the following QPU types: annealers,
fluxonium, ion trap, and fixed tunable. Note the scroll bar may be
used to reveal more types of devices in the menu. Once the device
type is selected the user can move on to the next step in the
selection process by clicking, or other selection action, on the
"proceed" button 2112. Should it be necessary the user can also go
back to an early step in the process by clicking, or other
selection action, the "back" button 2111. Progress through the
process can be readily seen in the "step" indicator 2113.
[0205] The next step is available in the GUI 2200 of FIG. 22, a
user is able to choose the number of qubits or "Qbits" 2201 in a
plaquette. The user can select the number of qubits by using the
slider 2202 or entering the number directly in box 2203, or by a
similar interactive method. Once the number of qubits is selected
the user can move on to the next step in the selection process by
clicking, or other selection action, on the "proceed" button 2212.
Should it be necessary the user can also go back to an early step
in the process by clicking, or other selection action, the "back"
button 2211. Progress through the process can be readily seen in
the "step" indicator 2213.
[0206] The next step is available in the GUI 2300 of FIG. 23, a
user is able to choose the qubit ("Qbit") or gate quality 2301 for
the gates/qubits in the plaquette. The user can select the quality
of qubits or gates by clicking, or other selection process, the
desired quality button 2302--in this example silver, gold or
platinum. Once the number of qubits is selected the user can move
on to the next step in the selection process by clicking, or other
selection action, on the "proceed" button 2312. Should it be
necessary the user can also go back to an early step in the process
by clicking, or other selection action, the "back" button 2311.
Progress through the process can be readily seen in the "step"
indicator 2313.
[0207] The next step is available in the GUI 2400 of FIG. 24, a
user is able to choose the topology 2401 for the configuration of
qubits in the plaquette. The user can select, by clicking or
otherwise, a topology from the menu 2402, which in this example
include the following configurations of qubits: linear, ring, star
and fully connected. Note the scroll bar may be used to reveal more
topologies in the menu. Once the topology is selected the user can
move on to the next step in the selection process by clicking, or
other selection action, on the "proceed" button 2412. Should it be
necessary the user can also go back to an early step in the process
by clicking, or other selection action, the "back" button 2411.
Progress through the process can be readily seen in the "step"
indicator 2413.
[0208] FIG. 25 shows an example of an interactive screen--GUI
2500--that can be used to book plaquettes on a QPU. A wire frame
type representation 2501 of the configuration of qubits and
qubit-qubit connections on a QPU is shown in the top right-hand
corner of the GUI. Information on different plaquettes available on
the QPU is provided; in this example they are all 4 qubit
plaquettes. The information includes wire frame representations
2502 of the plaquettes, showing the topology and connectivity of
the plaquettes, performance details 2503, which can include readout
fidelities, one qubit gate fidelities, two qubit Bell state
fidelities, etc., a price to rent the qubit, in this example given
in dollars per minute, and a "select" button 2504, which can be
used to select the plaquette, and in some embodiments may be used
to directly purchase the plaquette. FIG. 26 shows the same
interactive screen as in FIG. 25, but after a user has selected
plaquette A. The selected plaquette A is clearly indicated by one
or more of: a "selected" button 2604, which may be given a color
that causes the button to stand out; a highlighted area 2606
surrounding the wire frame representations 2602, the performance
details 2603, the price to rent the qubit, and the "selected"
button 2604; and the selected qubits 2607 are seen to be
highlighted in the wire frame representation 2601 of the QPU. A
"continue" button 2605 can be used to move on to the next page of
the booking interface, which in some embodiments may be a payment
page, and in other embodiments may be a purchase confirmation page,
if the "select" button 2504 is a direct purchase button.
[0209] Furthermore, in some embodiments an interactive screen may
be provided to a user that allows the user to check the
quality/performance data for individual qubits and edges in a wire
frame representation of plaquettes and qubits on a QPU. The user
may access this information by: moving a screen cursor over a qubit
or edge, selecting a qubit or edge, etc. Selection and/or movement
of a screen cursor may be achieved using a mouse, a touch screen,
hand tracking, eye tracking, tapping, as part of an augmented
reality or virtual reality experience, etc. Furthermore, in some
embodiments a wire frame representation of a quantum processor may
show particular properties of qubits and edges by using different
colors, heat maps, size of qubit, thickness of edge, etc. to
represent the value of specific properties on a sliding, discrete
or calibrated scale.
[0210] In some embodiments, billing and metering of usage can be
done while preserving customer security and an agreement that the
service provider won't inspect the semantics of the user's programs
or how the user is using their data. Information regarding billing
and metering may be accessed through a web interface such as
described above.
[0211] Some of the subject matter and operations described in this
specification can be implemented in digital electronic circuitry,
or in computer software, firmware, or hardware, including the
structures disclosed in this specification and their structural
equivalents, or in combinations of one or more of them. Some of the
subject matter described in this specification can be implemented
as one or more computer programs, i.e., one or more modules of
computer program instructions, encoded on a computer storage medium
for execution by, or to control the operation of, data-processing
apparatus. A computer storage medium can be, or can be included in,
a computer-readable storage device, a computer-readable storage
substrate, a random or serial access memory array or device, or a
combination of one or more of them. Moreover, while a computer
storage medium is not a propagated signal, a computer storage
medium can be a source or destination of computer program
instructions encoded in an artificially generated propagated
signal. The computer storage medium can also be, or be included in,
one or more separate physical components or media (e.g., multiple
CDs, disks, or other storage devices).
[0212] Some of the operations described in this specification can
be implemented as operations performed by a data processing
apparatus on data stored on one or more computer-readable storage
devices or received from other sources.
[0213] Data-processing apparatus encompass all kinds of apparatus,
devices, and machines for processing data, including by way of
example a programmable processor, a computer, a system on a chip,
or multiple ones, or combinations, of the foregoing. The apparatus
can include special purpose logic circuitry, e.g., an FPGA (field
programmable gate array) or an ASIC (application specific
integrated circuit). The apparatus can also include, in addition to
hardware, code that creates an execution environment for the
computer program in question, e.g., code that constitutes processor
firmware, a protocol stack, a database management system, an
operating system, a cross-platform runtime environment, a virtual
machine, or a combination of one or more of them.
[0214] A computer program (also known as a program, software,
software application, script, or code) can be written in any form
of programming language, including compiled or interpreted
languages, declarative or procedural languages, and it can be
deployed in any form, including as a stand-alone program or as a
module, component, subroutine, object, or other unit suitable for
use in a computing environment. A computer program may, but need
not, correspond to a file in a file system. A program can be stored
in a portion of a file that holds other programs or data (e.g., one
or more scripts stored in a markup language document), in a single
file dedicated to the program, or in multiple coordinated files
(e.g., files that store one or more modules, sub programs, or
portions of code). A computer program can be deployed to be
executed on one computer or on multiple computers that are located
at one site or distributed across multiple sites and interconnected
by a communication network.
[0215] Some of the processes and logic flows described in this
specification can be performed by one or more programmable
processors executing one or more computer programs to perform
actions by operating on input data and generating output. The
processes and logic flows can also be performed by, and apparatus
can also be implemented as, special purpose logic circuitry, e.g.,
an FPGA (field programmable gate array) or an ASIC (application
specific integrated circuit).
[0216] While this specification contains many details, these should
not be understood as limitations on the scope of what may be
claimed, but rather as descriptions of features specific to
particular examples. Certain features that are described in this
specification or shown in the drawings in the context of separate
implementations can also be combined. Conversely, various features
that are described or shown in the context of a single
implementation can also be implemented in multiple implementations
separately or in any suitable sub-combination.
[0217] Similarly, while operations are depicted in the drawings in
a particular order, this should not be understood as requiring that
such operations be performed in the particular order shown or in
sequential order, or that all illustrated operations be performed,
to achieve desirable results. In certain circumstances,
multitasking and parallel processing may be advantageous. Moreover,
the separation of various system components in the implementations
described above should not be understood as requiring such
separation in all implementations, and it should be understood that
the described program components and systems can generally be
integrated together in a single product or packaged into multiple
products.
[0218] A number of embodiments have been described. Nevertheless,
it will be understood that various modifications can be made.
Accordingly, other embodiments are within the scope of the
following claims.
* * * * *
References