Ket Runtime Architecture¶

Ket applications communicate with the runtime library Libket, and Libket communicates with the quantum simulator KBW

Ket is a hybrid classical-quantum programming language designed to run on a classical computer coordinating a cloud-based quantum computer. Ket’s runtime architecture assumes that quantum computers process in batch (without interaction during the execution) to reduce the decoherence effects. Ket also provides a live execution mode, that facilitates the analyses and debugging of quantum applications on simulators.

Components¶

Ket has three components, the language Ket, the runtime library Libket, and the quantum simulator Ket Bitwise Simulator (KBW).

Ket is a Python-embedded classical-quantum programming language that friendly exposes the Libket functionality. A ctypes wrapper of Libket’s C API provides Ket’s built-in types and functions.
Libket is a Rust runtime library for quantum programming that provides all the tools necessary to create a quantum application. Being independent of the Ket language, one can link a quantum application directly to Libket, cutting the Python overhead. Libket also provides a C API which one can use to integrate Libket into other programming languages.

Libket does not execute the generated quantum code but passes it to a quantum executor. For the Ket language, the default quantum executor is the KBW simulator. It is possible to change the simulator at runtime.

KBW is a quantum simulator based on the Bitwise Representation that can execute all of the instructions issued by Libket. KBW’s Sparse simulation time is independent of the number of qubits, allowing to simulate 30+ qubits when working with a low amount of superposition. For example, the code below presents the execution time to prepare a GHZ state with 80 qubits on a Intel® Core™ i5-1340P.

from time import time
import ket

begin = time()
p = ket.Process(num_qubits=80, simulator="sparse")
q = p.alloc(80)
ket.ctrl(ket.H(q[0]), ket.X)(q[1:])
d = ket.dump(q)
end = time()

print(d.show())
print(f"Execution Time = {end-begin}s")
# |00000000000000000000000000000000000000000000000000000000000000000000000000000000⟩        (50.00%)
#  0.707107         ≅      1/√2
# |11111111111111111111111111111111111111111111111111111111111111111111111111111111⟩        (50.00%)
#  0.707107         ≅      1/√2
# Execution Time = 0.0004601478576660156s

Runtime¶

The result of a measure in Ket with batch execution is not available soon after, allowing Libket to append multiple measurements at the same quantum execution. With this in mind, we can split Ket runtime into classical and quantum runtime.

At the classical runtime, the classical computer executes classical operations that do not depend on not available measurement results as usual. On the other hand, quantum instructions generate calls to Libket. Libket uses this call to forge a quantum code with every information needed for quantum execution.

The quantum runtime begins when the classical computer needs some result from the quantum computer. At this time, Libket sends the quantum code for quantum execution and waits for the results. Libket is agnostic of the quantum execution target and cannot communicate with it during the quantum execution when using batch execution mode. At the end of the quantum runtime, Libket writes the results from the quantum computer on the classical one.

A quantum execution has three possible types of results, measurement from a measure or sample, expected value from exp_value, and QuantumState from dump, with the last, only possible on simulated quantum executions.

Process¶

Every quantum operation communicates with a Process inside Libket, which handles the references to the quantum computer and the creation of the quantum code. So every Quant, Measurement, Samples, ExpValue, and QuantumState variable belongs to a process. Interaction between processes is not possible.

Measurements¶

Ket’s measure function returns a Measurement variable that holds a reference for the measurement result in the quantum computer. The classical computer can request this information by calling the function get, which triggers the quantum execution. After the quantum execution, one can call the get attribute without activating another quantum execution.

Alike, the results of Samples, ExpValue, and QuantumState variables are only available after the quantum execution, and calling a function to read the result will trigger the quantum execution.