PyZX circuit support

PyQrack v0.4.6 adds experimental support for PyZX Circuit definitions as an intermediate representation for QrackSimulator. To try this, load a Circuit in PyZX, (use that module to optimize your circuit, as you like,) and create a QrackSimulator() instance using the pyzxCircuit named argument of the constructor, like so:

sim = QrackSimulator(pyzxCircuit=c)

where c is a PyZX circuit object. The circuit will automatically be simulated in the constructed QrackSimulator instance. This also allows loading from QASM and other intermediate representations supported by PyZX.

Also, reversing the state of v0.4.5, the none/any wheel includes all available binaries from the author, while building from source assumes an installation of the underlying Qrack library from source.

Concurrent simulator instances

This release refactors the concurrency handling in the underlying Qrack shared library interface binary. A "meta-" mutex synchronizes shared library simulator management by STL containers, as previously. However, the "meta-" mutex is now released once a new QrackSimulator-specific mutex is locked, for operations limited in scope to dispatching simulator methods. Hopefully, with (mostly intuitive) Python threading best practices, this reduces contention and increases stability in Python environments performing asynchronous threads of operations on different simulators.

It is important to note, PyQrack and Qrack will attempt to distribute new demand for simulation RAM to every available device in descending order of immediate device load, with the (environment-variable-selectable) default device preferred in load balancing contest ties. It is also possible, but not typically recommended, to control via environment variable whether PyQrack reactively redistributes unbalanced loads, instead of only redistributing through balancing new demand. (In the case of load-redistribution being activated, the device any load is currently on is preferred in case of redistribution ties, before default device.) Also, at a very low level, argument hooks for OpenCL kernels are device-specific, and cause thread contention on the combination of device and kernel call, like the kernel for the general single qubit gate, underlying many named single qubit gate methods. See the vm6502q/qrack repository README for more information about these environment variables.

The none/any wheel is main branch. However, we now package all wheel binaries together in the build-from-source distribution on PyPi, to maximize device market share coverage for the sake of users.

Reduced OpenCL program size

One of the OpenCL kernels in the underlying Qrack library was redundant with OpenCL v1.1 APIs. This kernel has been cut. (Compiled OpenCL program size can be a limited resource, so it is important to generally minimize program size, depending on trade-offs with performance, but there is no such trade-off in this case.)

Also, Linux shared libraries are now loaded according their local links (or "shortcuts"). This makes it possible, in the future, on Linux x86_64 and other systems, to properly alias shared libraries as per the conventions of the GNU linker.

CPU-fallback and ARMv7

This adds binaries that will automatically fall back from OpenCL to pure C++11 CPU-only simulation, if 0 OpenCL devices are present in the system. Also, an ARMv7 binary/wheel has been tested and is now fully supported.

Since the available wheels comprise the full extent of the PyQrack developer's ability to compile and support binaries, and the vast majority of systems that can use these binaries will select the appropriate wheels, none_any default wheel will match main branch and assume that vm6502q/qrack will be built and installed custom on the desired system.

Quality-assured build variants and wheels

Hypothetical PyQrack builds have been cut, for which vm6502q/qrack builds but PyQrack hasn't or can't be tested. Momentarily, this only leaves us with x86_64 builds across Linux, Mac, and Windows, and 32-bit x86 builds for Windows. Every one of these variants has a separate wheel with a minimum of unnecessary binaries.

Linux x86_64 wheel (and binary cleanup)

This adds a wheel specifically for Linux x86_64 systems that contains only the binaries necessary for that platform. In the near future, the same will be done for all systems we intend to support.

Also, the binary previously categorized as "ARM64" appears not to actually be for that platform. At least, it was compiled on a system presumed to be ARM64, but that system actually resolves a platform name of "armv7l". The binary selection has been updated accordingly.

Expanded special API

This adds additional optimized gates to the API, so as to help expose all useful Qrack optimization directly to Python.

Bugfix: mcu gate parameter casts

The mcu gate should internally cast its unitary angle parameters to c_double. This release adds the appropriate casts.

Bugfix: Fix QrackSimulator() cloning and __del__

The QrackSimulator() cloneSid named argument didn't work. If the user attempted to clone, the __del__ method tried to delete a simulator that didn't exist, within the shared library layer. This update fixes these bugs, and it does not require any shared library update.

Improvement: Better QUnitMulti device scheduling

This release updates the Qrack binaries for better default QUnitMulti device scheduling behavior, on systems with multiple OpenCL devices installed. This also adds a new environment variable to the underlying Qrack binary, QRACK_ENABLE_QUNITMULTI_REDISTRIBUTE, explained in the vm6502q/qrack README file. (Default behavior, without modifying the environment variables in use, should tend to work best, on most consumer home systems.)