You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The chosen strategy is to make all backends "cloud backends", in the sense that the user code will only hold a client, and talk to a backend server through a socket (possibly on the same machine).
The basic exchange of information will happen through serialization (of circuits and results).
Despite this strategy being very general, often it won't be optimal.
Thus, the following optimizations are candidates for a later implementation:
compiled backends
Unix sockets
shared memory communication
Compiled backends
Sometimes, when the backend itself could be linked to the user application (because it is written in a compiled language, or the user is unlikely willing to link the whole interpreter... the performance gain should be negligible...) it could be nice to have a CompiledBackend struct for execution, instead of a ClientBackend.
This could be supported with an enum (essentially, the usual manual version of enum_dispatch).
Unix sockets
These are not portable, but they would gain in performance over TCP ones, when running on the same machine.
Shared memory
Instead of serializing the results, a pointer to shared memory could be returned.
This is a valid strategy for execution on the same machine (giving permissions to both server and client to access the result memory) but also to handle results on discrete devices (like handling a buffer on a GPU).
The text was updated successfully, but these errors were encountered:
The chosen strategy is to make all backends "cloud backends", in the sense that the user code will only hold a client, and talk to a backend server through a socket (possibly on the same machine).
The basic exchange of information will happen through serialization (of circuits and results).
Despite this strategy being very general, often it won't be optimal.
Thus, the following optimizations are candidates for a later implementation:
Compiled backends
Sometimes, when the backend itself could be linked to the user application (because it is written in a compiled language, or the user is unlikely willing to link the whole interpreter... the performance gain should be negligible...) it could be nice to have a
CompiledBackend
struct for execution, instead of aClientBackend
.This could be supported with an
enum
(essentially, the usual manual version ofenum_dispatch
).Unix sockets
These are not portable, but they would gain in performance over TCP ones, when running on the same machine.
Shared memory
Instead of serializing the results, a pointer to shared memory could be returned.
This is a valid strategy for execution on the same machine (giving permissions to both server and client to access the result memory) but also to handle results on discrete devices (like handling a buffer on a GPU).
The text was updated successfully, but these errors were encountered: