Add PyQrack backend option #274
Conversation
Prep for pyqrack==0.3.0 release
|
Hi @WrathfulSpatula! I'm really happy to see a new backend for SimulaQron 🎉 I briefly looked at the code and looks very good to me. But I will tag @bvdvecht here since I'm no longer at QuTech and Bart has taken over the main responsibilities :) That being said I do still care a lot about SimulaQron so feel free to reach out it you have any issues/questions. imo since SimulaQron doesn't have a full-fledge plugin system I would say that it makes sense to merge this into SimulaQron, in a similar way QuTip, ProjectQ etc is handled but will let @bvdvecht decide. |
|
Sorry for the late response. I'm excited to see a new backend for SimulaQron! The backend code and unit tests seem fine to me and I agree that it's good to just merge this into SimulaQron. Before doing that, it's probably good to make sure that the With CQC being the main way of programming for SimulaQron at the moment, I also tried running some of the examples while having Qrack as the SimulaQron backend. Unfortunately it seems that applications with remote entanglement generation (e.g. teleportation) will crash; I think it has to do with accessing a qubit that is simulated on another node. I'm not sure however if this has to do with the Qrack backend itself, or that SimulaQron's implementation makes some assumptions about the backends that Qrack doesn't match, and in which case maybe the backend interface itself should be changed. Maybe @AckslD has an idea what's going on exactly? |
|
@bvdvecht Do you have a traceback from the crash? :) |
|
By the way, we're still iterating the underlying Qrack API for a v6.2 release. ("PyQrack" is the name given to the Python binding layer over the shared library C interface, and this SimulaQron backend is specifically using the PyQrack layer.) I notice, in my personal tests of PyQrack, we try to engage multiple OpenCL device parallelism by default, but platform interoperability can cause instability when multiple device parallelism might not even necessarily be desired. For example, my development machine has both an NVIDIA RTX 3080 and an Intel HD, with ICDs installed. PyQrack becomes unstable when both devices are visible to Qrack and the OpenCL environment, because either platform's buffer objects aren't recognized as proper, as a peer to the other platform's buffers, throwing I use VirtualCL for my experiments with Qrack clustering, and, if I use that virtualization layer to ban the Intel HD from my virtual platform, PyQrack is then stable. However, I'd like to add a native Qrack environment option for banning visible devices in the OpenCL environment, so that VirtualCL isn't necessary for this purpose. I could probably have that in PyQrack within a day or two. I'm saying, configuring the PyQrack environment is still a little tricky. Does either machine have multiple OpenCL devices available, as reported by So, no OpenCL device is necessary at all, to run Qrack or PyQrack on a single node, at least with PyQrack v0.4.4. I'd expect, by Qrack's design, that different nodes could alternatively rely on the pure C++11 CPU simulation or the OpenCL-based simulation at the same time, but I'm having trouble on the networking side for my own testing, of getting two physical Linux machines I have to connect via SimulaQron. |
This is the output for the teleport app. The error says If I change the teleport code of both Alice and Bob so there is literally only the So there is this |
|
I'm guessing, that's not the problem. It's likely in the limitations of my support for the SimulaQron backend API, or a mistake I made in indexing or labeling backend instance qubits. I'll have time experiment, tonight, if I can recreate your example. |
|
Brief update: I didn't realize there was a switch for backend type, in the teleport example. PyQrack encourages a native-quantum-hardware-like interface that can't directly query amplitudes, but, if I least add the conditional branch to say PyQrack won't do that, the teleport example works for me locally. I'm not sure exactly what code I should be testing, if not that example in 574a9f0. |
|
@WrathfulSpatula The teleport example @bvdvecht refers to is here and not the one in this repo. The ones here using the native mode which was basically only used in the development phase. However the intended way to interact with simulaqron it throught the CQC interface where there are modules in python, c, rust and others to more easily write applications. |
|
@AckslD Thank you for directing me to the right example. This probably doesn't help you folks much, but that example runs fine on my local machine with PyQrack as the backend simulator. (Honestly, to be sure that SimulaQron was actually using my configuration files with If that's the case, I'm guessing there's a problem with the compatibility of the Qrack binary's build options and your machine. Even though all binaries are built with OpenCL support, it should be from v0.4.4 of PyQrack on that systems with 0 OpenCL devices will automatically fall back to CPU-only simulation. I've tested this several times in the course of the past few days with two models of Raspberry Pi, 3 and 4. If there is at least one OpenCL device on the system, you might want to delete the This would surprise me, but it's possible your CPU doesn't have the RDRAND instruction. By default, Qrack uses this (on-chip hardware RNG) x86_64 instruction for random number generation. Hopefully, if the instruction isn't present, Qrack should fall back to (software-based) Mersenne Twister. However, the detection process for software fall-back could go wrong, depending on the system implementation. If this were actually the case, users would be expected to build Qrack from source, to support PyQrack, with Running into the RDRAND case would be a first for me, and I hope I'm not misleading you with it. But, the point is, for a system with 0 OpenCL devices, and any kind of architecture that I might consider exotic, users would generally build Qrack from source to provide a binary for PyQrack. Also, we're pure C++11 standard, (established in 2011,) we have 0 dependencies besides optional OpenCL, and we've tested builds on systems including Android and iOS, so your system is supported, in all likelihood, by careful design of the Qrack framework, but you still might need a custom binary build, if I can help in any way. |
|
Thanks for the pointers. I actually installed OpenCL now on my system (Ubuntu 20.04). ( after which I get the following: @AckslD If you have the time, I would be interested in seeing whether you are able to run this example with the |
|
@bvdvecht I actually hadn't added the CLI backend option for |
|
I just updated this to fix the conflicts with upstream work. Is there anything I can furnish, to help here? Occasionally, certain systems will benefit from a custom source build of the underlying C++ Qrack libraries, depending on hardware capabilities, and I wasn't sure if that might have been the case in the original tests we previously discussed, but most consumer systems should be fine with just default PyPi-distributed PyQrack, particularly by version v0.8.2, if you upgrade. |
Hi, I'm Dan Strano of the Unitary Fund, and lead developer of the high-performance, GPU-accelerated vm6502q/qrack quantum computer simulation framework. Last week, I wrapped our Qrack shared library interface in pure Python, to create PyQrack. Over the holiday weekend, I wrote back-end classes for both SimulaQron and Interlin-q. This pull request adds the PyQrack backend to SimulaQron, including unit tests.
The PyQrack back-end will transparently function somewhat like your stabilizer back-end, while PyQrack can still switch on-the-fly to full "Schrödinger method" "ket" simulation, without any in-depth knowledge or special configuration by users. Qrack internally identifies when it can run instructions as stabilizer, and simply maintains stabilizer representation for as long as it can, including in qubit subsets, if some separable qubit subsystems can maintain stabilizer representation while others can't. In fact, we "Schmidt decompose" our subsystems as well, treating identifiable separable subsystems as smaller "ket" simulations, with no special attention necessary from the user when acting entangling gates across separable subsystem boundaries. (This is inspired by work by Pednault and team, on Schmidt decomposition in the simulation of quantum circuits.) This adds significant overhead relative to the original CHP by Aaronson, for example, upon which our stabilizer "layer" is directly based, but Schmidt decomposition is intended to give a different set of advantages, in addition to our stabilizer layer.
I realize that it might be better if this back-end for SimulaQron stands on its own, in a separate plugin repo, or a fork. However, I hoped to start a discussion of that, here in this pull request. I'm interested in quantum network simulation as an alternative to Intel-QS type MPI-based "paging" parallelism for high-performance quantum computer simulation. Thank you for the awesome quantum network simulator, by the way!