✨ Multicore Support

[mnfarooqi]

What's the problem this feature will solve?

The recent development of new quantum multicore device architectures, for instance that of planqc's “Multicore Atomic Quantum Computing Systems” (MAQCS) (https://www.lrz.de/en/research/research-projects/detail/maqcs), underscores the necessity to introduce support for architectures with more then one processing unit within the QDMI interface. The specification needs to be sufficiently flexible to accommodate not only homogenous architectures with quantum processing units that bear similarity to the concept of cores and threads in classical computing, but also potential heterogeneous architectures in the future.

The objective of the interface would be to facilitate the ability to address each processing unit for the query, as well as the job interface. Therefore, in the case of a noise model that has been queried, a noise-aware compiled circuit may be submitted to the same processing unit.

Note: Only a subset of the issue was addressed by PR #200.

FYI:
@echavarria-lrz
@burgholzer
@ystade
@AdVetter

Describe the solution you'd like

I can think of three ways to achieve this, which I will outline below. The first two will involve breaking changes, whereas the third will not.

1. Introduce a new opaque pointer for the abstraction of a quantum processing unit that can represent a core, thread or chiplet. This opaque pointer can replace the device pointer in the interfaces used for querying and submitting jobs.
2. Add an additional argument to the query and job submission interface functions to represent the processing unit ID.
3. Introduce a new function (e.g. 'select_qpu'), which can be used to set the active core/thread/chiplet in the device pointer. This determines which core/thread/chiplet is targeted in all subsequent calls to the query and job interfaces.

[ystade]

@mnfarooqi thanks for opening this issue. I'll first summarize my understanding of the new architecture to make sure that I did not msunderstand anything and then argue why it is already covered by the current implementation of QDMI.

The MAQCS offers mutliple processing units (cores) that can be addressed and controlled individually. Hence, it is possible to start a job on one core while another job is already running on another core. Nevertheless, it is possible to shuttle (move) qubits from one core to the other if necessary. Hence, these cores are somehow coupled and do not represent individual devices.

Following the hardware description, I'll outline now, why I think, this scenario is already fully covered. Regarding the query of fidelity and coherence data, the respective functions allow to query such data for specific sites. For example, if one would like to average the coherence time over one processing unit, one queries the coherence time for every site in one processing unit and calculates the mean. In conclusion, each core is sematically equal to a zone on zoned architecture, see also #200.

However, I see one remaining issue, which I would argue is (almost) solved: Since each core can be addressed individually and multiple jobs can be executed independently in parallel, it must be possible to submit jobs while another job is already running. This part is already possible with the current interface because the function to submit a job is not forced to block until the job is done. However, the user might be interested whether a given job can be directly executed (while others might already be running). Here, I would propose to add a new boolean property of the list of job properties that can be queried. Based on the used qubit indices in the job, the device then reports, whether this job could immediately run when it would be submitted. This property could be named QDMI_JOB_PROPERTY_RUNELIGIBLE. If true, the job does not conflict with any currently running jobs and could be scheduled without delay. If false, the job would be queued until the required qubits become available. This would allow users to make more informed decisions about job submission timing and optimize resource usage more effectively.

To summarize, to cover the new architecture, I would just add the property QDMI_JOB_PROPERTY_RUNELIGIBLE and leave the rest as is.

[burgholzer]

I very much like the minimal proposal.
Some bikeshedding on the name is probably needed.

• ISDIRECTLYEXECUTABLE
• EXECUTABLE
• READYTORUN

I'd also believe that it needs slightly more than just this simple property.
A compiler would want to query which sites/zones/cores are currently occupied or, vice versa, which are free for computations. This has to be tracked somewhere in the stack and I guess QDMI would be the right place for it. Eventually, it's the device itself that knows best where jobs are currently running/scheduled.

[ystade]

A compiler would want to query which sites/zones/cores are currently occupied or, vice versa, which are free for computations. This has to be tracked somewhere in the stack and I guess QDMI would be the right place for it. Eventually, it's the device itself that knows best where jobs are currently running/scheduled.

This raises the question whether this status should be reported in a site level (––> would only require a new site property) or whether it should be required for the actual core/unit (––> would indeed require a new entity or a refactoring of the site entity such that we employ a hierarchy on sites where the current sites are the leaves of this hierarchy).

[burgholzer]

A compiler would want to query which sites/zones/cores are currently occupied or, vice versa, which are free for computations. This has to be tracked somewhere in the stack and I guess QDMI would be the right place for it. Eventually, it's the device itself that knows best where jobs are currently running/scheduled.

This raises the question whether this status should be reported in a site level (––> would only require a new site property) or whether it should be required for the actual core/unit (––> would indeed require a new entity or a refactoring of the site entity such that we employ a hierarchy on sites where the current sites are the leaves of this hierarchy).

We do have ZoneSites by now. Wouldn't these be perfectly adequate here?

[ystade]

I am uncertain... the purpose of the zone sites is to define an extent global/zoned operations can act on. There is no mechanism apart from checking coordinates to retrieve regular sites contained in a zoned site. Intuitively, if I would have something like zone/core/unit in the setup discussed here, I would expect that I can query that entity for all contained sites. Additionally, it does not make too much sense to me, saying "this area/extent (which a zone site represents) is currently occupied by a job" because not the area rather than the actual sites are occupied. However, both might also just be me-problems.

[burgholzer]

I am uncertain... the purpose of the zone sites is to define an extent global/zoned operations can act on. There is no mechanism apart from checking coordinates to retrieve regular sites contained in a zoned site. Intuitively, if I would have something like zone/core/unit in the setup discussed here, I would expect that I can query that entity for all contained sites. Additionally, it does not make too much sense to me, saying "this area/extent (which a zone site represents) is currently occupied by a job" because not the area rather than the actual sites are occupied. However, both might also just be me-problems.

Nah, you are right with what you are saying. It's not an ideal solution.
I just feel that querying the availability on a per-site basis is a little too fine-granular for the scenario here.
At the moment, I don't have a better suggestion though.

[mnfarooqi]

The MAQCS offers mutliple processing units (cores) that can be addressed and controlled individually. Hence, it is possible to start a job on one core while another job is already running on another core. Nevertheless, it is possible to shuttle (move) qubits from one core to the other if necessary. Hence, these cores are somehow coupled and do not represent individual devices.

My understanding of the cores and their capabilities is quite different. Let's say we have a device that has multiple cores, where you can schedule multiple jobs to run either sequentially or in parallel. Also, it is not possible for qubits to be connected to or move between different cores. How would the following two use cases (for job submission) be handled with #200.

1. Run a circuit on a specific core: If I understand correctly, one would map the circuit onto the qubits of a zone/core.
2. Distribute the number of shots of a circuit across different cores: Would the same circuit need to be duplicated/triplicated/... and mapped separately to qubits of different zones?

[ystade]

My understanding of the cores and their capabilities is quite different. Let's say we have a device that has multiple cores, where you can schedule multiple jobs to run either sequentially or in parallel. Also, it is not possible for qubits to be connected to or move between different cores.

Then we should clarify the capabilities of the architecture first before we speculate here what it can do and what not. My information stems from Johannes I was talking very briefly with at the MQV meeting.

How would the following two use cases (for job submission) be handled with #200.

1. Run a circuit on a specific core: If I understand correctly, one would map the circuit onto the qubits of a zone/core.

Since the qubits must have unique ids, the respective workload of the job just refers to different qubits depending on which core is selected to run the job on.

2. Distribute the number of shots of a circuit across different cores: Would the same circuit need to be duplicated/triplicated/... and mapped separately to qubits of different zones?

If the cores are not connected then I would strongly argue that the cores are just separate QDMI devices. This scheduling aspect that you mention here is then handled on higher levels but should not be part of the hardware.

[mnfarooqi]

My understanding of the cores and their capabilities is quite different. Let's say we have a device that has multiple cores, where you can schedule multiple jobs to run either sequentially or in parallel. Also, it is not possible for qubits to be connected to or move between different cores.

Then we should clarify the capabilities of the architecture first before we speculate here what it can do and what not. My information stems from Johannes I was talking very briefly with at the MQV meeting.

I am not sure how much I can disclose about the device under development on this platform. Perhaps @AdVetter could explain it better, or we could discuss it offline.

How would the following two use cases (for job submission) be handled with #200.

1. Run a circuit on a specific core: If I understand correctly, one would map the circuit onto the qubits of a zone/core.

Since the qubits must have unique ids, the respective workload of the job just refers to different qubits depending on which core is selected to run the job on.

As far as I understand, depending on the device's internal architecture, it may need to analyse the workload to identify the zones in which the circuits need to be scheduled. I was wondering how this analysis would scale with a growing number of qubits. The specifications need to be designed carefully so that they do not cause problems later on while solving a problem today.

2. Distribute the number of shots of a circuit across different cores: Would the same circuit need to be duplicated/triplicated/... and mapped separately to qubits of different zones?

If the cores are not connected then I would strongly argue that the cores are just separate QDMI devices. This scheduling aspect that you mention here is then handled on higher levels but should not be part of the hardware.

Let's not dismiss it so quickly. I could not find a definition of "device" in the QDMI documentation. A device with multiple unconnected cores could share many internal resources. Therefore, a standard definition of a device is required here that aligns with the community's understanding of what constitutes a device.

Furthermore, a concrete proposal is needed on how this can be handled at a higher level. My understanding of QDMI is that it is an interface that connects software to hardware. If QDMI does not expose the functions that hardware may provide, how can this problem be solved at higher levels?