Pool of devices and async execution of multiple active devices supports #381
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #381 +/- ##
=======================================
Coverage 99.56% 99.56%
=======================================
Files 43 43
Lines 7546 7559 +13
Branches 497 497
=======================================
+ Hits 7513 7526 +13
Misses 17 17
Partials 16 16 ☔ View full report in Codecov by Sentry. |
maliasadi
changed the title
We currently lower the device name, kwargs, and library with 3
`__quantum__rt__device(key, spec)` calls. The runtime initializes the
targeted device after getting the device name and kwargs at the third
call:
```
__quantum__rt__device("rtd_name", "lightning.qubit");
__quantum__rt__device("rtd_kwargs", "{...}");
__quantum__rt__device("rtd_lib", "rtd_lightning.so"); <--- init device
```
This PR reduces the number of these device calls into 1 single
`__quantum__rt__device_init("rtd_lib", "rtd_name", "rtd_kwargs")` call
and deprecates the `__quantum__rt__device` instruction. The runtime is
able to initialize the device without necessarily storing partial device
info or implying any specific order to define these specifications in
the IR and the runtime. This PR is related to
#381 and will help better
scope the lifetime of device instances. We also add
`__quantum__rt__device_release()` to release the initialized device by
request (this'll be used in the async support).
---------
Co-authored-by: David Ittah <dime10@users.noreply.github.com>
There was a problem hiding this comment.
Great work @maliasadi 🎉 🎉
I mostly have some comments and questions to pin down the role of different components, but happy to approve otherwise :)
|
There's a frontend test in test_compiler that tests the writing a program using MLIR as a string. I think we need to add the new quantum instruction release there as well. |
|
We also need to reconsider what happens now if the runtime throws an exception. |
There was a problem hiding this comment.
@maliasadi, this is looking good! I will mark this as approved but I now think we should wait to merge it until the async support is more worked out. I would like the async support for finite difference to be working well. You mentioned you wanted this merge as it would facilitate my work but I think it is ok, I can always rebase :). I'll let you and @rmoyard coordinate on this.
PS: don't forget to fix the frontend test in test_compiler.py
|
@erick-xanadu Thanks! There is no rush to merge this PR if it doesn't contribute to your progress. I'll apply the remaining suggestions today and will ping you for the rebase. Let's ensure end-to-end support before merging 💯 |
There was a problem hiding this comment.
Great work @maliasadi! Thanks for answering my questions! I let you answer David's comments and questions (that I also share) and you can consider that is all good on my side 👍
There was a problem hiding this comment.
Thanks @maliasadi, this looks great! A few last questions about the interaction of the CAPI and the execution context, then I'm happy with it 💯
Context:
The runtime now supports multiple active devices managed via a device pool. The new
RTDevicedata-class andRTDeviceStatusalong with thethread_localdevice instance pointer enable the runtime to better scope the lifetime of device instances concurrently. With these changes, one can create multiple active devices and execute multiple programs in a multithreaded environment.Add
DeviceReleaseOpto the Quantum MLIR dialect. This will be lowered to the__quantum__rt__device_release()runtime instruction updating the status of the device instance fromActivetoInactive. The runtime will reuse this deactivated instance instead of creating a new one automatically at runtime in a multi-qnode workflow when another device with identical specifications is requested.[sc-47651]