Transcript | A New Quantum Software Development Kit — With Anne Matsuura of Intel

Thank you so much, Konstantinos. It’s nice to be here.

I got to see you at a CQE event. It’s so wonderful to have you here with us. I know you have a Ph.D. in physics, which is an expected way to get here, but can you tell our listeners how you found your way to working with quantum computing specifically?

I’ve been working in the quantum space most of my career, even though not always in quantum computing. My first research was in understanding the quantum physics behind how complex materials with interesting electronic and magnetic properties — things like the high-temperature superconductors —work. And even though that was not quantum computing itself, one of the interesting things is that an application for a large-scale quantum computer of the future is probably the simulation of complex electronic materials like high-temperature superconductors. So I feel, in a way, that my career has come full circle, but throughout my career, I’ve always gravitated toward what’s the most exciting job, the next project, to work on, and that’s led me to work in varied roles.

For instance, I was a strategic investor of startup companies at a little strategic investment firm. I was the chief executive of an organisation that provided analysis of experimental data from large light sources, or synchrotron facilities, where I used to work. I was the chief scientist of an optical nonprofit. And now the most exciting thing to me is to be leading the system architecture and the software side of the quantum programme at Intel.

And most of this episode is going to be focusing on a great quantum SDK from Intel that I got to play with recently. But before we move into that, when people hear Intel, of course they think of CPUs, they think of hardware. It’s been a traditional association. Is there anything that you could share on a roadmap to have an Intel QPU in the near future?

I’m guessing by QPU, you mean the qubit chip itself.

Yeah. Quantum processing unit.

But in reality, many of the functions of a quantum processor unit are contained in the Intel Quantum SDK. For instance, our quantum control processor, which tells the control electronics what pulses to send to the qubits and when, is software, and it’s part of the SDK package. But as far as the qubits themselves, I don’t lead that part of the effort. But we do expect to have a 12-qubit quantum dot chip by end of year. We’ve chosen quantum dot qubits, as they’re a perfect match for Intel’s fabrication facilities. These qubits look like one-electron transistors.

And we can leverage Intel’s fabrication expertise and our silicon expertise. We have a dedicated 300-millimeter process node for fabricating wafers full of qubit devices, and we can also do wafer-level testing at cryogenic temperatures. We are leveraging our expertise in making chips for classical computing in our process for making qubit chips for quantum computing. And we believe that it’s 10 to 15 years out for big, practical, scalable, commercial-sized quantum computing systems that can regularly do useful things that are intractable for classical computers.

For more of the fault-tolerant advantage. And with this proposed 12-qubit chip, in some ways, this SDK is preparing people for programming it, because on the back end, you’re ultimately going to be selecting a simulator of a quantum system. That moves us on to version one of the Intel Quantum SDK. Do you want to give our listeners an overview or a high-level description of the general approach and how it works?

The Intel Quantum SDK is a full quantum computer in simulation. It includes a real compiler that efficiently optimises your algorithm, and decomposes your quantum programme into operations that are available on the Intel Quantum qubit chip. The SDK is written in C++ using an industry-standard LLVM layer, which is standard for classical compilers, that we’ve extended with quantum extensions.

This will, in the near future, enable us to open-source the front end of the compiler and allow users to contribute their own compiler passes or use whatever quantum compiler front end they prefer to target this LLVM layer in the near future. We’re getting good feedback from classical computer engineers on ease of use for them. With the standard C++ formatting and the standard look and feel of our compiler, it’s optimised for usage with hybrid quantum classical algorithms, which are very popular workloads today. The SDK also has a quantum runtime environment that manages the execution of the quantum programme. And there are two target qubit back ends contained within the SDK.

And people have been coding for a while — some people have been in quantum in general. Is there a way to use any other types of preexisting code from other environments and convert it to the SDK?

Yes. We have a QASM translator at the front end of the SDK so that one can input the same code that they’ve written for other quantum software, and this translator translates it into C++ code that is compatible directly with our SDK.

Are there any plans with that open sourcing of the front end to make it interact with other higher-level environments — anything like graphical or any cloud platforms — in the future?

We hope, by open sourcing the front end of the compiler probably later this year, that we’ll be able to be open to those sorts of things.

When this code is written, what are the back ends? So far, you said, there are a couple. What kind of back ends are people going to see now?

In our current version of the SDK, we have two qubit simulators as your target back ends. One is a state-vector qubit simulator that’s made to run on multiple computational nodes. You can simulate up to, like, 29 qubits on a single node, and generally more than 40-some qubits on multiple nodes. And the second qubit target back end is a simulation of Intel’s quantum dot qubits. As you said, in the future, one of the back ends will be the Intel qubit hardware itself.

You mentioned some qubit limitations there. These are still with the state vector simulation — there are memory limitations. Obviously, every time you add a qubit, you’re doubling the amount of RAM and some other resources needed. I’ve heard of some approaches where you can avoid keeping track of all the data and allow for higher qubit counts — temporarily forget some and bring it back, if that makes sense.

You might be talking about that we also have another kind of qubit simulator back end that we have internally at Intel, and we probably will make it available in the near future as well. That’s a tensor-network qubit simulator. This will allow for hundreds of qubits, if not more, but it’s used mainly for shallow, simpler algorithm circuits rather than the complex ones that we’ve been talking about — the hybrid quantum classical ones. But that is something that we probably will also put in a near-term version of the SDK.

I have to mention that because people always say, why is 50 the limit for simulation? You have to keep track of it. And with those other tensor approaches, you can have more qubits that disappear. There’s no high depth count for the gates.

That’s right. The current vector-state qubit simulator that is available as a back end, I want to make clear that it’s not the simulator itself that’s limiting the number of qubits. As you alluded to, it’s the amount of computational resources needed so it can simulate as many qubits as you have the computational resources for. It just so happens that you need an awful lot of computational resources.

Yeah, exponential growth is a tricky thing. You don’t want to turn the planet Earth into a computer just to have 100 qubits, but it also shows the power of quantum computing in the future. Do you see any quantum-inspired algorithms working with any of these machines? I was curious about that.

That’s a very interesting area — and a way that quantum computing has actually been interesting to the classical computing world in an unexpected way, in that thinking about writing a quantum algorithm has inspired developers to write better classical computing algorithms. Yes, the Intel Quantum SDK could also be useful in working in such an area.

I view that as an amazing ROI: You have classical hardware, and it’s error free, mostly, unless you get into cosmic rays and things like that, which is a totally different conversation. For someone who hasn’t used this before, in general, what’s the workflow like? What happens realistically if you’re using the Intel Quantum SDK?

The user puts in a single source file, a quantum programme, into our compiler, which the compiler breaks into basic quantum blocks of the algorithm and classical blocks of the algorithm. We have a suite of algorithm optimisations that are implemented by the compiler, and it does the mapping and scheduling of the algorithm that also happens in the compiler. Then the compiler emits a binary executable file that’s then loaded by the quantum runtime into the quantum control processor — which is also software — which tells the simulated control electronics what pulses to send to the qubits and when to send them. And then, of course, we have the qubit simulators themselves at the end.

It really does work like a computer. You asked about the compiler itself. You can do the same sorts of things that you can do with a classical compiler. You can compare compiler files from our SDK to see exactly how your algorithm has been optimised. That’s often done in the classical compiler world. Also, for quantum classical algorithms, the hybrid algorithms, you need to compile the algorithm only once rather than needing to compile for each algorithm iteration.

Can you talk about the quantum runtime library and how it works with instructions? I was reading about the dynamic parameter update, which seems useful if you know how to code for it.

The quantum runtime manages the execution of the programme, and part of that management is sending only the data required by the quantum logic. It’s responsible for knowing which memory locations to get values from and which quantum instructions to supply them to. The quantum runtime library intercepts those instructions and dynamically updates those parameters. This is a particularly useful function for efficiently running these hybrid quantum/classical algorithms.

I agree. For people who are going to be new to this, we’re going to get to how you access it in a moment. But I noticed that obviously, it’s new, so it’s still light on any sample reusable code. There are a couple of basic programmes. I was looking in the quantum examples directory, and there are just a handful of things there, and some things you expect to see — Deutsch-Jozsa, things like that. But are there any thoughts on building a whole community around the SDK, providing people with code they can experiment with — for example, Snippets — if you want to do a financial application or something like that?

Yes. Our aim is to build an ecosystem of users who are interested in using the Intel Quantum SDK and contributing examples. We already have a couple hundred users, because they started as beta users, and we’re collecting more examples from these users all the time. For instance, Lidos Corporation has been a great user of the SDK, mainly for simulation of materials, and there are a lot of universities that are using it, like the Deggendorf Institute of Technology — they’ve been working on fluid dynamic problems.

We have these kinds of applications and more from our users, including even things like studying black holes. These are, of course, all very small algorithms. These are toy problems where you can then scale the algorithm to run on the large, commercial-scale quantum computers that we’ll have in the future, but we’ve given out grants to computer engineering professors to use the SDK in teaching their quantum coursework. We really do expect that these use cases will proliferate. We have a communities forum on the Intel dev cloud, but we hope to expand into larger forums as time goes by. As software providers, we’re open to all applications, and we value feedback from our users on functionalities that they would like to see provided in future versions of the SDK so that they can run examples from their favorite quantum application area.

It might be good to have a whole hackathon devoted to the SDK, and then that’ll encourage people to freely share how they solve the problem.

That’s an idea that has come up, and that may very well happen. We’ve held an Intel Quantum SDK challenge. We’ll run another one later in the year, but in January, we had one based on our beta users, held in Munich. And in this challenge, mostly students applied to give 15 minutes talks to explain what they’ve done with the Intel Quantum SDK. And we gave out awards for what we thought was the best usage of the SDK. But those are ways in which to find what kinds of applications are being used and find example code as well.

Yes. In the future, when you give out grants, it should be a legal requirement that they give away the code at the end.

Well, it’s an interesting point. They have agreed to open-source their coursework — their slides and stuff — so that people can pick it up and use it.

That’s free documentation right there. Not free, but it’s out there — free to the user. And to anyone listening, here might be a chance to make a name for yourself with a brand-new platform if you could be the one that solves a problem or creates a novel approach. That’s a good way, because it’d be difficult to do that right now in something like the Qiskit community, where there’s not quite that much code out there.

For folks who have used HPC environments before, let’s talk a little bit about the dev cloud. How does that compare? People want to understand it. It is free — for listeners to understand right off the bat? And we’ll be putting a link in the show notes to how you can sign up and get an account. What kind of limitations can users expect when they sign up for this free account?

The Intel Quantum SDK is open to everyone. But you have to sign up to become an Intel dev cloud user first. The link that you’re going to show will link to a form that will tell you what to do. That form will point you to how to sign up as a user of the Intel dev cloud, which is free, and how to sign up for the Intel Communities form, which is also free and is a way to talk to other users of the SDK. And that’s all while you’re gaining access to the SDK. And after you gain access to the SDK, you will hear from us. We’ll you a tutorial to walk through how to use the SDK. And we’d love your feedback on this part of the user experience as well. I think, Konstantinos, you may have gotten a part of the tutorial last week.

Yeah. That was a lot of fun. It made it a lot easier to play around with that. And I hope to, in the future, do a video or something where I’m using it or something like that. That might be wonderful.

Yeah, that would be great.

Are there any limitations? What kind of bandwidth, what kind of experimentation can people expect to do for this free service?

At the moment, the Intel dev cloud is still limited to one computational node, but we’ve been promised that that will expand in the near future. You may be limited closer to the 30-qubit limit at the moment, but we know that that will change in the near future.

And as you said, if you have more nodes, that’s when you’re hitting something like 40 qubits, somewhere in that neighborhood.

And are there any plans for pay versions, for heavy experimentation? Let’s say there’s a company that they’re all in — they love it — but they want to be able to do these monster experiments. Would there be a way for them to buy up access to multi-nodes?

Not at this time. I don’t know that there’s any plan to do that. That’s probably more of an Intel dev cloud question than for the quantum group. We do have some instances where we have given access if we sign a simple license, which for some reason tends to take a long time when legal gets involved. But we have in certain instances given tarballs of the Intel Quantum SDK to certain external entities so that they can put it on their own computation. Those have been rare events.

And it’s safe to say that for most people listening, 29, 30 qubits will probably be enough.

Cloud is the way to go for most people.

Bringing us back to the hardware in general, would you say if this chip, the microdot, it’s available this year, would that mean that users could expect within a year or so to be hitting a real back end target through this interface like that?

That might be a reasonable expectation. It depends on the robustness of the quantum dot qubit chip and what that exactly looks like by end of year. But we’re making very steady progress on fabricating more robust silicon quantum dot chips in our fab, and we expect there’ll be a 12-qubit chip by the end of year. Our ultimate goal at Intel — we’re always looking toward the practical, scaled-up version of this machine, and for that, there’s a much longer time scale. But you’re right — I would think in the coming years that there will be some sort of hardware back end to the SDK. But we feel that by rolling out the Intel Quantum SDK now ahead of the hardware, we aim to build an ecosystem of users who are comfortable with and want to use Intel’s quantum technology as one will, as you mentioned before, use the Intel Quantum SDK to access our quantum hardware in the not-too-distant future.

Horse Ridge has been out for a while, and this idea of Intel building other pieces of a quantum computer — control parts. Are there any plans for, let’s say, if someone were to build a quantum computer using some of that circuitry? Would there have been any plans to implement one of those other third-party systems through this environment as well?

There could be, but Intel is building the entire quantum computing system. When you say we’re building components, we’re building all the components of the full system, and that’s been intentional from the very beginning. We’re doing research at every layer of the computational stack — the hardware, the software, system architecture. At the moment, that’s Intel’s plan.

If you look at the industry, for example, Qiskit was to talk to IBM machines, but then all of a sudden, you can talk to IonQ machines with it, or there was some of that crossover because of the cloud model and everything. I was curious if there were any plans to have SDK talk to other kinds of back end targets for an end-user ease of experience — like, “No, I programme in Intel, and that’s what I know.” That kind of thing.

Well, one of the issues there is, you’ll need a new quantum instruction set for the different kinds of qubits, because our SDK models a complete computer. As I mentioned, part of the QPU is actually in the SDK — it’s the quantum control processor. And that orchestrates when control pulses are sent and what kind of control pulses they are. There would be a lot of recoding in order to implement different kinds of qubits.

And if I’ve learned anything when it comes to adding layers like that of recoding and transcoding, you do lose performance.

You need a new quantum instruction set. It wouldn’t just be recoding. It would be removing the compiler back end and replacing it with a different one.

That’s why it is best to be able to have that level of control, which is why it’s great that it’s all in one area, so it’s all right there for users to experiment with. Are there plans to make the simulated microdot, for example, reflect what the real one works like? Let’s say you do have a 12-qubit one that’s on the cloud, accessible, and it has a certain noise profile. Are you going to then introduce that to the simulator so people who are experimenting will be able to gauge what it’ll be like on the real machine?

That’s exactly the reason for the quantum dot qubit simulator back end, which is a simulation of the Intel Quantum dot qubits.

I’s going to match up perfectly with how it behaves in the real world, or as close as possible.

Well, if you wanted to be perfect, you’d need a quantum computer to do such a thing, to simulate such a quantum dot material. And of course, we’re not using a device-level Quantum dot qubit simulation either, because that would also could take you weeks to run. We’re using the basic physics for our Intel Quantum dot qubits is in this qubit simulator. It is a good approximation of how the Intel Quantum dot qubits operate.

To everyone listening, as we mentioned, you can import code from QASM, so if you’re an experienced programmer, there’s really no reason to delay giving this a try. It’s easy to get started, and if you’re new, then this can be one of the first things you try because of its excellent documentation and user-friendly environment. If you have C++ programming experience, that obviously will come in handy here.

Are there any other tips you can suggest for our listeners to get going?

One of the reasons we wrote our SDK and C++ is to try to encourage classical programmers, classical computer developers, into the quantum computing area. Hopefully, you will find that this does remind you of some of the classical computers that you are used to, although it’s a totally different kind of compute methodology. Also, I’m very proud of how the team has built this SDK. It’s very robust. It’s working very well. It works particularly well for hybrid quantum classical algorithms. I also encourage physicists who are experienced with quantum algorithms, please give this a go. Or if this is, like you said, their first time using quantum computing, please give this a go and give us your feedback. We’d love to learn from you and find out how to make it better.

Those are great points, because one of the most common questions I get is, “How do I get started? I have a classical programming background,” or “I’m in physics,” so it sounds like there’s an area here for both types to play with this tool and learn more. That’s why I wanted to have you on. I’m really excited for the SDK and using it more.

Thank you very much, Konstantinos. I really appreciated your invitation to be on the show with you today.

Now, it’s time for Coherence, the quantum executive summary, where I take a moment to highlight some of the business impacts we discussed today in case things got too nerdy at times. Let’s recap. Intel is working on a 12-qubit quantum dot processor, leveraging the company’s immense experience in manufacturing silicon. As with any quantum computer, this QPU will be part of a stack of supporting hardware and software. The quantum control processor that controls the QPU with pulses and so on is software. Intel is allowing users to start experimenting with this stack via the Intel Quantum SDK, which is a full quantum computer and simulation.

When you access the Intel Quantum SDK via the Intel developer cloud, you are given access to a compiler that optimises your algorithm and decomposes your programme into operations that will run on two back end simulators. One simulator can handle multiple nodes to allow for more than 40 qubits. The other is a simulator of the forthcoming 12-qubit quantum dot chip. The SDK is written in C++, so some developers will feel right at home. And, in case, you’ve already worked with OpenQASM code, there’s a translator to import your past work. The SDK works well with variational hybrid quantum classical algorithms.

For now, the environment contains only a handful of code snippets available to build off, but Intel is hoping to build an ecosystem of users who may share example code of their own. Give it a try, and maybe contribute some of your own experiments. Check out the link in the show notes to sign up and run code for free.

That does it for this episode. Thanks to Anne Matsuura for joining to discuss Intel’s quantum SDK, and thank you for listening. If you enjoyed the show, please subscribe to Protiviti’s The Post-Quantum World and leave a review to help others find us. Be sure to follow me on all socials @KonstantHacker. You’ll find links there to what we’re doing in Quantum Computing Services at Protiviti. You can also DM me questions or suggestions for what you’d like to hear on the show. For more information on our quantum services, check out Protiviti.com or follow ProtivitiTech on Twitter and LinkedIn. Until next time, be kind, and stay quantum-curious.