Introduce new Executor primitive incorporating samplomatic semantics#78
Introduce new Executor primitive incorporating samplomatic semantics#78delapuente wants to merge 23 commits into
Conversation
Drafting the initial justification.
|
|
| offers two such primitives: the Sampler and the Estimator. The Estimator | ||
| leverages advanced error mitigation techniques to enhance the quality of | ||
| results from noisy quantum computers. On a noiseless quantum computer, the | ||
| Estimator could instead be constructed atop the Sampler, simplifying its role. |
There was a problem hiding this comment.
The purpose of the Estimator extends beyond just mitigating noise. It also adds a layer abstraction around the concept of estimating observables, allowing implementors of Estimator interfaces to offer different methods for observable estimation (e.g. classical shadows) while preserving a common interface.
There was a problem hiding this comment.
I will include this as part of the explanation of the Estimator purpose.
| inefficient, but this can be optimized using a "samplex" — a domain-specific | ||
| language (DSL) program describing the way of producing these variations. The |
There was a problem hiding this comment.
The description of a "samplex" as a DSL is odd. It feels more like a data structure than a DSL to me. Is this RFC going to include a section on sampling graphs?
There was a problem hiding this comment.
I've always compared the sampling graph as data transformation steps but I may be missing insight that would translate in a more natural explanation of the sampling process. I'll investigate about it.
There was a problem hiding this comment.
The system of decorating boxes with twirling annotations feels like a DSL. The samplex is a graphical representation of circuit transformations.
There was a problem hiding this comment.
Agree. I made the language and the control flow graph the same but that's a non-trivial leap and separating those concepts would make it more clear. Let me work on the rewording.
blakejohnson
left a comment
blakejohnson
left a comment
There was a problem hiding this comment.
This RFC seems to introduce 3 concepts:
- Sampling graphs (
samplex) ExecutorprimitiveQuantumProgramdata structure
However, (2) and (3) aren't described at all beyond their appearance in the example. (1) gets the most motivating text, but the RFC doesn't actually say enough about what it is beyond something that produces circuit variations.
In short, this looks rather incomplete at this stage.
Co-authored-by: Blake Johnson <blakejohnson04@gmail.com>
| variations. Transmitting these variations across cloud environments is | ||
| inefficient, but this can be optimized using a "samplex" — a domain-specific |
There was a problem hiding this comment.
To me this summary doesn't really capture the problem we are trying to solve. It reads as if the problem was this data transfer being inefficient. But we already solved that problem with Qiskit Runtime - i.e. by generating all the parameters on the server side. The problem is really that the existing Qiskit Runtime solution does not offer the transparency and flexibility users want.
There was a problem hiding this comment.
My rationale to justify this way is as follows:
If we would not have the data bandwidth problem, we could give the user a bare sampling primitive, and let them do the sampling of the noise model, and the parameter linkage on the client side. Instead, we offer a way of describing the sampling process so we transmit a "compact" summary of the process.
However, I agree with you when saying Samplomatic, and the samplex, do not solve the bandwidth problem: any other sampling graph would accomplish the same. Samplomatic offers a sound framework for sampling, and the fact that is open source accounts for the transparency we were looking for. Do you think this goes more in the direction of your expectation?
| Users and researchers seek finer control over these techniques to improve the | ||
| reliability of quantum computations, especially on noisy quantum hardware. |
There was a problem hiding this comment.
This sentence reads a bit odd to me. I think it'd help to provide concrete examples - e.g. people want to experiment combining different EM methods (like PEA + PEC), or they want to apply different scale to different parts of their circuits to reduce cost.
There was a problem hiding this comment.
I think this is a very good idea, would you mind suggesting the changes, please?
| transmitting thousands or millions of circuit variations. By shifting variation | ||
| generation to the backend through a portable DSL, researchers can run advanced |
There was a problem hiding this comment.
But we are not shifting this. Variation generation is already done on the server side, at least for Qiskit Runtime. Performance is not the problem we are trying to solve. It's just something we need to consider when solving the real problem.
There was a problem hiding this comment.
Agree. When I review the previous argument, I will update this as well.
| Today, Qiskit users can already run large-scale error mitigation experiments, | ||
| but the process is **implicit** — it is difficult to explain and difficult to | ||
| compose, and users have no direct control over how circuit variations are |
There was a problem hiding this comment.
This is actually a Qiskit Runtime problem, not a Qiskit problem. Mitiq, for example, does their error mitigation on the client side. But then that solution hits the performance issue you described. So samplex is really a solution to address both transparency/flexibility + performance concerns.
There was a problem hiding this comment.
I see what you mean. I will rephrase in terms of a vendor-agnostic challenge and see how Qiskit can help in mitigating that challenge.
| # Prepare circuit for executing | ||
| template, samplex = samplex.build() | ||
|
|
||
| with Session(backend=backend) as session: |
There was a problem hiding this comment.
Session is a Qiskit Runtime only concept, so it's a bit odd to show up in this example. I believe the reason is to ensure there is no long gap between learning and mitigation... but how would other vendors that don't support Session solve this issue?
There was a problem hiding this comment.
The scope of this RFC does not include solving the drifting issue. However, I wanted to highlight some mechanism is needed if wanting to keep learning, and sampling close.
There was a problem hiding this comment.
I agree solving this issue is out of the scope. But it's probably worth mentioning this is a potential issue introduced by this new interface.
There was a problem hiding this comment.
This is now addressed in its own section.
| # The proposal wants to acknowledge the transtionary reality in which the | ||
| # primitives continue being the entry point for operating the quantum computer | ||
| # and this is a low level interface for advanced usage. | ||
| from qiskit.primitives.implementation import QuantumProgram, Executor |
There was a problem hiding this comment.
What does this mean? The title of the RFC says "low level Sampler", so is this Executor a replacement of Sampler? Yet here it seems to imply the primitives (sampler and estimator) are not going away ?
There was a problem hiding this comment.
The Executor is the low level sampler. When I started the RFC branch, I called it that way, and then Ian came with the Executor name.
Yet here it seems to imply the primitives (sampler and estimator) are not going away ?
Yes, they are not going away. The fact the Executor is in an implementation package is my attempt to mitigate your concern regarding primitives going away. It was my understanding we don't want them to go away but to expose a "low-level interface".
There was a problem hiding this comment.
The Executor is the low level sampler.
Perhaps the word sampler is overloaded here. If I understand you correctly, Executor is not an implementation of the sampler primitive - i.e. it does not implement the Sampler interface defined in Qiskit. It is, however, a program that does sampling, hence it's a lower level "sampler".
If this is correct, I'd still avoid calling it a low level sampler. Otherwise people might be confused thinking it's an implementation of the existing sampler interface.
delapuente
changed the title
| The Estimator leverages advanced error mitigation techniques to enhance the quality | ||
| of results from noisy quantum computers. On a noiseless quantum computer, the | ||
| Estimator could instead be constructed atop the Sampler, simplifying its role. | ||
| However, given current noise levels, robust error mitigation is essential, | ||
| requiring executing thousands or even millions of circuit variations to implement | ||
| certain mitigation protocols. Transmitting these variations across cloud environments |
There was a problem hiding this comment.
Here we should distinguish between the estimator abstraction, which says nothing about mitigation, and our IBM hardware implementation---the primitives service---that has options to enable it.
| # The proposal wants to acknowledge the transtionary reality in which the | ||
| # primitives continue being the entry point for operating the quantum computer | ||
| # and this is a low level interface for advanced usage. | ||
| from qiskit.primitives.implementation import QuantumProgram, Executor |
There was a problem hiding this comment.
I expect that the Executor in this snippet will need to come from qiskit-ibm-runtime instead: it needs to do things like POST to our service.
Instead, base class like BaseExecutor would like in the SDK proper.
I'm also wondering how this might all fit in with BackendV3, @ElePT , @jakelishman , @mtreinish : we might consider not having an Executor at all and reverting to something more like backend.run(). In this case we might need to have different semantics for sessions/batches than we have today.
There was a problem hiding this comment.
I expect that the Executor will need to come from qiskit-ibm-runtime instead: it needs to do things like POST to our service.
They need to, same as sampler and estimator.
I'm also wondering how this might all fit in with BackendV3, @ElePT , @jakelishman , @mtreinish : we might consider not having an Executor at all and reverting to something more like backend.run(). In this case we might need to have different semantics for sessions/batches than we have today.
I think this requires understanding how this proposal affects the "primitives model" of execution we currently have. Will this replace the primitives? complement the primitives? I don't know how we could reasonably justify reverting to backend.run() if the sampler and estimator primitives continue existing...
There was a problem hiding this comment.
They are not incompatible, in a timeline. Let's introduce the Executor first, then figure out if this way of operating could establish a new compute model. This idea is explored in Future extensions.
There was a problem hiding this comment.
Ok, I'm going to try to imitate the RFC for the Estimator in which the imports are not displayed, and elaborate on the concepts, then we can think of a strategy for adding this to Qiskit.
|
|
||
| ## Future Extensions | ||
|
|
||
| The introduction of a low‑level sampler is only the first step. The long‑term |
There was a problem hiding this comment.
| The introduction of a low‑level sampler is only the first step. The long‑term | |
| The introduction of a low‑level sampler (called an executor) is only the first step. The long‑term |
| Vendors like IBM have identified that users desire capabilities for precise | ||
| noise learning, twirling, and expectation value calculations. | ||
|
|
||
| This proposal will enable Qiskit users to perform large-scale, backend-optimized |
There was a problem hiding this comment.
If we want to be precise... this would be Qiskit IBM Runtime users. But I think it's ok to use the broader sense of Qiskit here.
There was a problem hiding this comment.
This is important. For landing in Qiskit, the new primitive needs to be of utility for vendor-agnostic users. I'd say we need an abstraction for the samplex. Even if it is pure definition. Once the correct abstractions are out there, I can think of other providers implementing different ways of creating samplex-like objects for their specific implementations. Don't you think?
| # The proposal wants to acknowledge the transtionary reality in which the | ||
| # primitives continue being the entry point for operating the quantum computer | ||
| # and this is a low level interface for advanced usage. | ||
| from qiskit.primitives.implementation import QuantumProgram, Executor |
There was a problem hiding this comment.
I expect that the Executor will need to come from qiskit-ibm-runtime instead: it needs to do things like POST to our service.
They need to, same as sampler and estimator.
I'm also wondering how this might all fit in with BackendV3, @ElePT , @jakelishman , @mtreinish : we might consider not having an Executor at all and reverting to something more like backend.run(). In this case we might need to have different semantics for sessions/batches than we have today.
I think this requires understanding how this proposal affects the "primitives model" of execution we currently have. Will this replace the primitives? complement the primitives? I don't know how we could reasonably justify reverting to backend.run() if the sampler and estimator primitives continue existing...
Co-authored-by: Elena Peña Tapia <57907331+ElePT@users.noreply.github.com>
Refactor the description of the samplex DSL for clarity and consistency. Improve the explanation of its role in error mitigation and its benefits for users and developers.
Delve into the key concepts of the Executor primitive, and its relation with samplex annotation and the samplex data structure.
Clarify the reasoning behind the decision to avoid saving user-generated samplex in the client and emphasize the importance of local generation for inspectability and debuggability.
Reframe to balance focus on the Executor primitive as a programming model, and introducing randomization semantics in Qiskit.
Refine the demo and detailed design of the RFC.
| An alternative to introducing the **samplex** DAG is to generate all circuit | ||
| variations entirely on the client side and transmit them to the backend for | ||
| execution. This approach offers maximum flexibility and complete control over | ||
| how variations are produced, since the backend would simply execute the | ||
| provided circuits without influencing their structure. Users could implement | ||
| any custom error mitigation workflow they wish, with no restrictions imposed by | ||
| backend capabilities or vendor‑specific optimizations. |
There was a problem hiding this comment.
There is be another, more efficient alternative to "[generating] all circuit
variations entirely on the client side," which is to simply generate templates and parameters. However, a benefit of the samplex is that it allows generating parameters "on the fly:" vendors can set up their stack in such a way that their QPU can execute a set of parameters while a new set of parameters is being generated by the samplex. This can significantly speed up execution, with respect to both alternatives
There was a problem hiding this comment.
Did not realize passing the samplex enabled lazy generation. Thank you.
Co-authored-by: Samuele Ferracin <sam.ferracin@ibm.com>
9 participants
This RFC proposes the introduction of a new Executor primitive into Qiskit as a vendor-agnostic substrate for execution. The
Executorprovides three core components—Executor,ExecutorProgram, andExecutorResult—that capture the relationship between a programming model engine, its semantics, and its results.The immediate motivation is to make randomization semantics for error mitigation explicit and first-class in Qiskit. Today, such workflows are implicit and opaque; this RFC standardizes how users express their intent through annotations and portable representations. This enables reproducibility, fine-grained control, and composability, while letting providers implement and optimize their own expansion engines.
This RFC does not introduce a specific engine such as IBM’s Samplomatic into Qiskit. Instead, it defines the substrate and user-intent representation, leaving execution engines to providers. Follow-up RFCs may propose additional semantics, a reference
Executor, or reimplementations of existing primitives (e.g.,SamplerandEstimator) atop this foundation.