ProjectQ icon indicating copy to clipboard operation
ProjectQ copied to clipboard

Qrack GPU-accelerated simulator

Open WrathfulSpatula opened this issue 6 years ago • 11 comments

(This pull request took the work of #283 and reverted and squashed to back to a manageable point.)

The Qrack simulator framework provides optional support for OpenCL-based quantum computer simulation on GPUs, CPUs, and any device supported by OpenCL.

To build with the Qrack simulator, install the Qrack framework from https://github.com/vm6502q/qrack and then build ProjectQ with the global option "--with-qracksimulator". The Qrack simulator will be exchanged for the default ProjectQ C++ simulator, throughout.

The vm6502q organization will finish the WIP by completing coverage, including fixing the single XFAIL. We'll review that work internally before squashing it as a minimum of commits onto this pull request.

We're aiming for the minimum possible diff, just sufficient to enable optional Qrack support for ProjectQ at the current state of development, and indefinitely into the future. The vm6502q organization intends to contribute this integration under ProjectQ's Apache 2.0 licensing, or the license of the ProjectQ maintainers' choice, which we believe is compatible with our LGPL licensing for Qrack.

Please let me know any questions, comments, concerns, or general thoughts on the request for consideration. Thank you, again!

WrathfulSpatula avatar Jan 27 '19 21:01 WrathfulSpatula

Damian, Thomas, and the ProjectQ team, I think this is finally at a point where it's ready for your consideration. Apologies for the mess and verbiage, along the way, but the diff is manageable, now.

The vm6502q organization team wants to maintain support for this, in part because we already use it. The Qrack simulator is entirely optional, and it is turned off by default in your build. When enabled, though, ProjectQ can now support GPU-based simulation, as well as OpenCL devices in general, including CPUs and accelerators like the Intel Core HD. You might get a speed boost, depending on the particulars of the hardware configuration. To switch any ProjectQ-based application to GPU-based execution, all you have to do, most of the time, is build and install --with-qracksimulator as a global option.

We don't yet have native Hamiltonian simulation or "QubitOperation" support that's compatible through this wrapper, but those are coming. I want to point out, one of the decomposition tests only works with Qrack if the "low level instruction filter" is removed in that test, but I was hoping to ask you folks for ideas why. I'm hoping it's only incidental to the different set of gates that the Qrack simulator wrapper natively supports, but we'll fix it if it's a bug.

Your compiler is awesome! Like I said, we already use it. With the SimulaQron quantum network simulator on top of this branch, it effectively enables cluster and multiprocessor support for Qrack, in a way that we think might be ideal for us. We hope this is useful to you, too!

WrathfulSpatula avatar Jan 29 '19 21:01 WrathfulSpatula

The merge CI failed on a package pull for the environment. I will trigger another build, soon, possibly after finishing a PR that's currently open on the Qrack repo.

WrathfulSpatula avatar Feb 05 '19 17:02 WrathfulSpatula

I should mention, we added support for QubitOperator expectation values and native time evolution capabilities, per your simulator interface. We do not support nonunitary operations, including nonunitary QubitOperator gates. (However, unitary QubitOperator gate applications should work fine.) Again, to enforce unitarity, we require that the most significant half of bits passed to a multiplication gate are treated as a "carry" register. Up to those considerations, I think we support your entire simulator interface.

This works with SimulaQron and PennyLane, although a small amount of numerical precision is sacrificed for speed and compatibility with 32-bit systems, depending on build options. This also works on the Raspberry Pi 3 VideoCore GPU.

WrathfulSpatula avatar Mar 16 '19 01:03 WrathfulSpatula

I'll be looking into the CI failures over the next few days. This is the first time I've seen that particular unit test fail, but I'll diagnose it and complete coverage.

WrathfulSpatula avatar May 09 '19 02:05 WrathfulSpatula

Now that I've pulled the update, I do reproduce this error locally. It's specifically one failing test for the phase estimation gate, which looks like it was worked on recently.

As Qrack introduces a small amount of additional floating point error for compatibility with GPUs and different architectures, the problem might very well be at the intersection of this difference in error and a probabilistic element to the test. I will have time during the next couple of evenings to diagnose and debug, as well as over the weekend. However, the update for Qrack itself only added the option to precompile OpenCL programs, which should make no numerical difference, in this or any case, as far as I know.

WrathfulSpatula avatar May 09 '19 12:05 WrathfulSpatula

The PR that was recently merged in checks for exact floating point equality to quantities such as 0.5, as the result of the phase estimation algorithm. Likely, successful results on that algorithm will cluster closely around 0.5, for example, failing an exact equality check against 0.5. It's possible that the success rate expectation could be higher, but I do not know what the expected success rate of the algorithm is, off the top of my head.

WrathfulSpatula avatar May 10 '19 01:05 WrathfulSpatula

apt-get install failed. Triggering another build.

WrathfulSpatula avatar May 11 '19 17:05 WrathfulSpatula

I've determined that the skipped amplitude amplification test fails due to a bug in Qrack::QUnit. I am sitting down to fix this, right now. (Thank you for the unit tests, by the way.)

WrathfulSpatula avatar Oct 05 '19 16:10 WrathfulSpatula

If I restore the test but comment-out just the line where complex_algorithm() is applied, the test works. This narrows my search significantly. I anticipate having a fix by tonight.

WrathfulSpatula avatar Oct 05 '19 18:10 WrathfulSpatula

Commenting-out complex_algorithm() out would make the test "trivial," but, fiddling along those lines, the it seems like things work "nontrivially" if I instead comment-out controlled All(X) gates. I think that's my issue. I'll restrict further commentary to a PR on our fork.

WrathfulSpatula avatar Oct 05 '19 18:10 WrathfulSpatula

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 3 committers have signed the CLA.

:white_check_mark: Takishima
:x: damiansteiger
:x: WrathfulSpatula
You have signed the CLA already but the status is still pending? Let us recheck it.

CLAassistant avatar Feb 13 '24 13:02 CLAassistant