Shared library qubit ID bounds checking

The shared library and WASM interfaces now raise exception if a qubit label is requested that wasn't already specifically assigned. (Previously, these interfaces simply returned the "0"-label qubit in this case, instead, which wasn't "unsafe," but the exception is more helpful.)

Full Changelog: vm6502q.v9.13.0...vm6502q.v9.13.1

sha1sum results:
9c0688c94a59b491f90f6ec667a36946f21d86f0 libqrack-macosx_14_0_arm64.zip
7ab1f8f90f0984776d50eb9024e212c0057a7d77 libqrack-macosx_15_0_arm64.zip
87ad5cc266d7a3945c0beefff0f1e05e8950ee29 libqrack-manylinux2014_x86_64.zip
ffbec900e4a77ab3b48ab9c42035961918373c64 libqrack-manylinux_2_35_x86_64.zip
df32dcf2b69686286197dc93e7c4244e3e30a3fe libqrack-manylinux_2_39_x86_64.zip
fe957ff79952d0818763d576311351ba3d5ccebc libqrack-win-amd64.zip

QCircuit direct to string in shared library

This feature release adds two new functions to the shared library API that, when used together, allow a QCircuit to be converted directly to a std::string representation (exactly the same as the file representation) and passed back to the shared library caller.

This release does not affect static linkage (like PennyLane Catalyst) at all, except in the context of WASM.

Full Changelog: vm6502q.v9.12.39...vm6502q.v9.13.0

sha1sum results:
952fc677b4560da9eea319126754fccbf840e42d libqrack-macosx_14_0_arm64.zip
1a4b8849b4c55ba182d9c19b531c1af9b5c0ec55 libqrack-macosx_15_0_arm64.zip
56b0e04a17964279497909de0a4efe0d3432f2fc libqrack-manylinux2014_x86_64.zip
b4779ed4a177689c599d8992c286f1816417c93d libqrack-manylinux_2_35_x86_64.zip
a648b6d66940f0159760e4e365fcc182ff6f63da libqrack-manylinux_2_39_x86_64.zip
fa421492c3ad225699031e929938c0404f898393 libqrack-win-amd64.zip

CodeQL warnings and shared library debug

This patch fixes every previous CodeQL warning and an edge case in release()/Decompose()/Dispose() in the shared library.

The CodeQL warnings were purely "false positives." CodeQL wasn't wrong in principle, but it's not capable of detecting that manual bounds checking prevents bitLenInt (which is often an alias for an 8-bit integer) from getting stuck in infinite loops when iterating over vectors of qubit IDs, which could contain 64-bits worth of size_t capacity, but which can't possibly pass manual bounds checking with more entries than the capacity of bitLenInt. a3d9854 roundly prevents these warnings from ever becoming relevant at all, but it's in this release.

The edge case in the shared library likely couldn't be encountered in PyQrack at all, since it does not allow the assignment of arbitrary integer labels for qubit IDs. (They must be sequential.) However, the fix is still important to other potential uses of the Qrack shared library interface, downstream.

Full Changelog: vm6502q.v9.12.38...vm6502q.v9.12.39

sha1sum results:
4167f0cf8aa5bbbd13530036ed665dbd65bbfb56 libqrack-macosx_14_0_arm64.zip
31fc9e95ae085199014c124f3dbb14de299684c3 libqrack-macosx_15_0_arm64.zip
a77f78275add153f8be98d0d4277783e6d3948d5 libqrack-manylinux2014_x86_64.zip
c92166baf482af0f1a9a1a5f10d19986a87a8018 libqrack-manylinux_2_35_x86_64.zip
642dd6f3a6ba775b4c5515279fc46f0efb0f3141 libqrack-manylinux_2_39_x86_64.zip
4a63f841a154d56ac8d8e0439f20bbd07bf2ad11 libqrack-win-amd64.zip

Fix segfault for 1-qubit QUnit GetProbs()

5fa8e96 introduced a segmentation fault in QUnit::GetProbs() in the specific case that the QUnit instance has exactly 1 qubit. I estimate the severity of the vulnerability to be low: all tests so far have resulted in a "caught" segmentation fault rather than a silent one, likely because the first unsafe access to memory is always an attempt to write to memory address 0/NULL. The specific case of calling QUnit::GetProbs() for an instance with just one qubit is likely also uncommon in user code. With that said, please update immediately!

(Thanks to @cosenal for catching this!)

Full Changelog: vm6502q.v9.12.34...vm6502q.v9.12.38

sha1sum results:
817734795acef3344aca164ebd99ac0c246c6f13 libqrack-macosx_14_0_arm64.zip
ae1b73c2229958f503cab3f13b2bf5a1c7a71334 libqrack-macosx_15_0_arm64.zip
61162e30a2b4385b72eff87ca94369387607ef59 libqrack-manylinux2014_x86_64.zip
3ebf3994706d01529fa71b534a62c4cc26d9bb5d libqrack-manylinux_2_35_x86_64.zip
de5886e8894a94b5bbc99c642bdcb971ddf55d9f libqrack-manylinux_2_39_x86_64.zip
797c95b747d23fb5280193fa5c06aa51d4a3d367 libqrack-win-amd64.zip

Optimize and restore QHybrid

We got to the bottom of the problem with QHybrid performance, and, with apologies, it had nothing to do with either "driver changes" or "speculative execution": since QHybrid was first entered into the library, optimized methods on QEngineOCL and QEngineCPU remained without direct exposure via the QHybrid layer. Making sure that the full public API was exposed via QHybrid fixed the issue. (It blows my mind that we went this long without MAll() exposed from the wrapped types under QHybrid.) Similarly, the incorrect results from QPager are a known issue where the engine type doesn't work with numbers of qubits smaller than its threshold for at least two "pages" in the simulator type, which is entirely avoided by wrapping in QHybrid.

(I owe an apology for mouthing off. No one was going to realize this problem but me, but, when something seems to work in the library for literally years, and then I notice it's sub-optimal, it's easy to reflexively blame driver and firmware changes before setting out to fix the problem of necessity, anyway.)

Full Changelog: vm6502q.v9.12.33...vm6502q.v9.12.34

sha1sum results:
4e69a13d4e60c36b4b9a67ac57941d77f8e509a3 libqrack-macosx_14_0_arm64.zip
2711111874f806f63da1f50fe85716ba1fc73dd6 libqrack-macosx_15_0_arm64.zip
9b6420ed0f19d5681b9de217c692c2a974331070 libqrack-manylinux2014_x86_64.zip
6a47dd89fd307d092308b9b34dbf29bad858fea2 libqrack-manylinux_2_35_x86_64.zip
dc67626ae4d85d7b1ef552e5f594d5661b5628cb libqrack-manylinux_2_39_x86_64.zip
a02e714aa86e81ae4d04f5be3985f93e0e85252e libqrack-win-amd64.zip

Remove QPager from default stack

QPager appears to be bugged when QHybrid does not wrap it, possibly only in the case that QPager has a single "page" (which QHybrid would avoid, but QUnit without QHybrid would engage). Apologies for releasing many times in a day, but this version is the most performant and correct I can offer until I systematically debug QPager, which might take a day or two.

Full Changelog: vm6502q.v9.12.32...vm6502q.v9.12.33

sha1sum results:
11e92c9bedd6d837886bd3cc78a3c8ea4d759136 libqrack-macosx_14_0_arm64.zip
845c60ecbd3632bcc09db79c24ec97cfa6f8be27 libqrack-macosx_15_0_arm64.zip
f6b46f78577866fe33c36a353d0a6c0972a54b7f libqrack-manylinux2014_x86_64.zip
6b4d9042e316920a7d6dc799593b146b110d2ba4 libqrack-manylinux_2_35_x86_64.zip
d5ac81f41262c22d678680f5c7227ad4ce256eb4 libqrack-manylinux_2_39_x86_64.zip
6e6003f39a9bda8529972bdbde3c776ab4b2e667 libqrack-win-amd64.zip

QHybrid no longer necessary

For years, it was always the case that low qubit width run on GPU-based simulation methods "plateaued" at a certain higher value than CPU-based methods at the same width, because full GPU parallelism couldn't be engaged for small numbers of work items. To alleviate this condition, years ago, Qrack implemented QHybrid, to intelligently switch between GPU-based and CPU-based methods.

Apparently, NVIDIA has fixed this behavior at driver level. (Dan is not going to lie: he's a little "miffed" that no one pointed this out to us specifically, when we've had rapport with the CUDA-Q team in the past, and the first to smooth over this imperfection at software rather than driver level was Qrack.) Hence, QHybrid will remain available for legacy drivers and other vendors who can benefit from it, but this optimizing "layer" will be disabled by default.

Full Changelog: vm6502q.v9.12.28...vm6502q.v9.12.32

sha1sum results:
8b0e2d075220df4ba3594aba478aca105ba17f89 libqrack-macosx_14_0_arm64.zip
755d1e85a5fc38016834d97c749fdf42e744de49 libqrack-macosx_15_0_arm64.zip
cc6c7601857acf4a5f8fd7b332f8c00b63982dbd libqrack-manylinux2014_x86_64.zip
ba68e51795d586590023db9ee72748f405eed314 libqrack-manylinux_2_35_x86_64.zip
eb39c37e23d2e701717b2ef1164fe9c7d2b860b9 libqrack-manylinux_2_39_x86_64.zip
9f5d7ed4d5f0bcd86620ce31478afd5f0bf4d930 libqrack-win-amd64.zip

Improve QCircuit

In preparation for experiments in compilation, QCircuit has been slightly refactored: single-qubit gates are now allowed to combine with any multi-qubit gate that would otherwise block commutation (which should almost never incur any additional simulation overhead penalty for running the optimized circuit with Qrack), and checks for identity equivalence have been made fully exhaustive.

Full Changelog: vm6502q.v9.12.27...vm6502q.v9.12.28

sha1sum results:
9036e5b7adfc536e2d80132c4074cc390811434b libqrack-macosx_14_0_arm64.zip
844631d932658a2a7cb431ece6e94f1fa60468f7 libqrack-macosx_15_0_arm64.zip
3ec9ffcb19359bfd44be0a4bb137de967ec8a0b0 libqrack-manylinux2014_x86_64.zip
862adecfb1c5bb626a9cea83a1ede667ae021faf libqrack-manylinux_2_35_x86_64.zip
e22c31df75f1b2ec8e8dbfcc739cf9abb8925fc2 libqrack-manylinux_2_39_x86_64.zip
ab846ecbde6486097b8841888e8a86170c327c19 libqrack-win-amd64.zip

Debug QCircuit osstream

QCircuit operator osstream>> suffered from a bug where bitLenInt was not correctly cast to size_t before writing out to stream. This creates unprintable characters that could have easily crashed the output process. The problem was not recognized sooner because build settings for releases used to entail that the bitLenInt happened to be printable as an integer.

Full Changelog: vm6502q.v9.12.23...vm6502q.v9.12.27

sha1sum results:
3baf9397acce5b0cf46e89c9cdfcec4d793a33bd libqrack-macosx_14_0_arm64.zip
8b7dff9891357d829bff1ddcb12d00591ae80c11 libqrack-macosx_15_0_arm64.zip
ad7d5ccb9b17db1ffa6f5991921e5314bba29c01 libqrack-manylinux2014_x86_64.zip
7c2648cdda5a4079428fb7e0a9f2ab982cf331b0 libqrack-manylinux_2_35_x86_64.zip
34a9f21d254454d47a949b8574547c727adabeb0 libqrack-manylinux_2_39_x86_64.zip
3cb467eb5e97f13041309c00689ab5976ba13602 libqrack-win-amd64.zip

Option to disable low-fidelity exception

This release adds the option to disable the limiter exception on low QUnit fidelity estimate, by setting environment variable QRACK_DISABLE_QUNIT_FIDELITY_GUARD to any truthy value.

When QUnit encounters a situation where acting a coupler gate would require exceeding user-specified maximum system memory resources, it will automatically resort to replacing this gate with a "classical shadow" that will not require additional allocation. In the process, QUnit will decrease its internal first-principles unitary fidelity estimation under assumption that the classical shadow replacement effect is worst-case. If the fidelity estimate drops below floating-point rounding epsilon, QUnit will automatically throw to exit simulation early. However, particularly in cases of "anti-concentration," such as with universal random circuit sampling, this first-principles worst-case fidelity estimate might be very overly severe. In these cases, the worst-case fidelity estimate cannot necessarily be trusted not to be (potentially very) overly pessimistic, but the throw condition on low fidelity estimate can be disabled by assigning any value to environment variable QRACK_DISABLE_QUNIT_FIDELITY_GUARD.

Full Changelog: vm6502qv9.12.23...vm6502q.v9.12.23

sha1sum results:
ae444cabe5c39763f47ff5cbe06b713832bf921c libqrack-macosx_14_0_arm64.zip
46cabdd5b8ed27dd6d22e7aea49d2a71bc4af3de libqrack-macosx_15_0_arm64.zip
23e68617c04ffc1576f393fd5126ba9812fd0785 libqrack-manylinux2014_x86_64.zip
493c94804579a39c8d3d03e05e09d2bd864b42ed libqrack-manylinux_2_35_x86_64.zip
2a838d3440043f6884293d32a463ccaaf4efae38 libqrack-manylinux_2_39_x86_64.zip
b435cd44d55fa6890136c7df03252cb2301188ef libqrack-win-amd64.zip