Transcript | Run Superstaq to Boost Quantum Computing Performance— with Infleqtion

Quantum computing is a full stack, from hardware up to the programming interface. Find out how you can modify just one layer of this stack to dramatically improve the performance of your programmes in this episode of The Post-Quantum World. I’m your host, Konstantinos Karagiannis. I lead Quantum Computing Services at Protiviti, where we’re helping companies prepare for the benefits and threats of this exploding field. I hope you’ll join each episode as we explore the technology and business impacts of this post-quantum era.

Our guest today is the VP of quantum software at Infleqtion. I’ve had the pleasure not only of having him on the show before but also of working with him on events, customer workshops and some more technical projects you might hear about in the future. I’m thrilled to welcome back the first threepeat of The Post-Quantum World, Pranav Gokhale.

Thanks for having me as a threepeat. I appreciate it.

It’s always terrific to have you on. You first came on as cofounder of Super.tech. Could you give listeners a refresher or, depending on who they are, a quick intro to your background and the software focus of Super.tech?

This was a spinout of research I did with Professor Fred Chung, my Ph.D. adviser at UChicago. We were looking at building a quantum stack that was very cross-layer in the sense that we would take applications and tailor them for execution on very specific hardware rather than building a lot of abstraction barriers between. The core insight here is that abstraction barriers incur a lot of inefficiency. The software we’ve been developing is about removing those inefficiencies and getting practical results sooner than otherwise possible. We were acquired by ColdQuanta, now named Infleqtion, a year and a half ago. Now I lead the quantum-software efforts at Infleqtion.

Listeners might recall that when you were on last time, we were talking about benchmarking quantum computers using software, and the software behind the software was an earlier version of what we’re going to be talking about today. Do you want to talk about the evolution of SuperStaq?

Last month, we were excited to launch what is called the open beta of SuperStaq. This is our flagship quantum-software product. It’s a platform we’ve been developing for about two years now. We launched it in a very closed alpha to solicit feedback from users and figure out the roadmap for what we wanted to build and how we wanted to build it. Over that two-year period, we got a lot of valuable comments, reactions and usage from a variety of users, including universities like Northwestern University and University of Chicago, companies like Morningstar Financial, and national labs such as the Berkeley lab, the San Diego lab and the Argonne Lab. Many of those users ended up becoming loyal customers who would use their platform for optimising their stack.

I haven’t yet touched on what SuperStaq is, so I can give a quick précis of that. It’s an optimising platform for running quantum programmes on current quantum hardware. If we want to get more mileage out of today’s quantum computers, we need to have a very efficient compiler that can take applications and put them on the hardware as efficiently as possible. In a sense, it’s like more of the 1960s of classical computing, where programmers like Grace Hopper were actually stepping in into the mainframe and doing debugging — removing moths that had flown in, things like that.

Of course, the end user SuperStaq is not necessarily having to suffer the pain of working with the device physics of a quantum system, but we automate that process and do it in such a way that the end user can get the benefit of this automated compiler flow. In a nutshell, that’s what we’ve been developing, and now we’ve made it open to the whole world to use — and in fact, Konstantinos and I got the chance to run a live demo prior to this conversation.

That was pretty eye-opening, and it’s going to direct my questioning so users could be right there with us. Now, this is available to end users, which is exciting because of what you can unlock with these performance boosts. Could you tell our listeners at a high level how you access this tool and what those initial benefits could be so they can get a sense of what it’s like to use it? Right now, they’re visualising any number of things. What’s it like to even just use it?

The basic step is, there’s a website called SuperStaq.Infleqtion.com where you can just one-click, two-click sign up through Google or your email address. When you sign up, what you’re getting is a password — an API key. From there, anyone who’s familiar with writing a quantum programme, whether it’s with Qiskit or with Cirq or QASM, can directly plug in to SuperStaq.

For instance, a lot of our users are very familiar with Qiskit, which is a library that we love for running quantum programmes. Qiskit has all these abstractions — things like providers, which give you access to hardware and run jobs. We have, essentially, a SuperStaq provider where instead of submitting to the ordinary provider, you submit to the SuperStaq provider. The syntax, the usage, is pretty much identical, but the big difference is performance. When you run, even with the highest level of optimisation, a programme through Qiskit, oftentimes, once you get past a couple of qubits — maybe five through six — you start getting noise-hampered results. That makes it challenging to use a quantum computer for anything remotely resembling business-relevant use cases.

If you take the same programmes and run them through SuperStaq — direct the traffic through there — we do a lot of advanced optimisation of the programmes and then submit that to the quantum computer. The results you get back end up being orders of magnitude better to the point where I don’t want people to take my word for it. It’s worth trying out. It’s five button clicks to see it live.

When we did that demo together, it was so easy to see because for listeners, I understand, when you run quantum computers, you have to run them a lot of times. Then you have to look and see what answers you got. Then you have to decide if any of them are significant enough to prove that they’re the right answer. To rule out all the bad ones, you run it 4,000 times, and sometimes the right answer is only in a handful of times more in one case. It gets tricky. You can have 500 correct answers and then the rest are four-something in the wrong one, so it’s hard to find the right answer.

But when we did the SuperStaq live, it was so obvious. It was like almost every single run was the correct answer, and it was a huge difference. It sounds like hyperbole, but it isn’t. If you look at the before-and-after bar graphs, it’s quite impressive. That’s why I’m excited that this is available to people.

I can touch on why it delivers such surprisingly good results. There are a lot of great tools out there, including Qiskit, including Cirq, which are good for what I’d call traditional objectives that obviously make sense. For instance, if you have two gates in a row that cancel each other out, it’s better to remove those because you save some time and save some error accumulation. It’s like, if you have two NOT gates in a row, you get rid of those. That’s the base layer of what previous technologies have done and where we build on top of and in fact incorporate a lot of those open-source technologies into our platform.

But as we were building this, we found that there are a lot of things that are counterintuitive about running programmes that are not supported by open-source software packages. They’re all things that have to do with surprising aspects of quantum computing hardware. One example is — I have to retract what I just said, which is, sometimes you see two NOT gates, and you would think to remove them. That’s what, normally, Qiskit would do. But in fact, we find that oftentimes, leaving them in there is better for performance.

This is a technique called dynamical decoupling. It’s a very physics-aware technique where one has to see that on very specific hardware, if you apply extra gates, it protects the qubits from noise. It causes noise to operate counterclockwise at one time point and clockwise the other time point, and therefore, it cancels out. It’s this collection of techniques we’ve developed that are surprising and counterintuitive that end up having the biggest gains in performance.

Another example is crosstalk, much like being at a dinner party and trying to have a conversation with your neighbor, but there’s a loud neighbor next door. There are techniques you can do in a quantum system to mitigate this kind of noise as well. And it’s not noise that makes sense to a traditional compiler, because there’s no such thing as crosstalk — at least practically speaking — for nonquantum computing. But for quantum computing, there is, and you can cancel out that crosstalk with the right software. In a nutshell, that’s what we’ve been doing on the technology and R&D development side that we finally put out into this product.

On the show in the past, we’ve talked about things that can be done before we get to the error-correction days. One of the techniques is, of course, having knowledge of the device and what you can do to prevent errors from getting worse along the way. It sounds like you’re accomplishing that right here, which brings me to the next question: Which devices are you aware of with this tool? Which devices can you do these things for?

Several of them. On IBM, we’ve done a couple of years of focused development on their system. Another one is the Braket devices through Amazon Web Services. For instance, on Rigetti, we are able to use this dynamical decoupling technique to quadruple the lifetime of a qubit.

One of my favorite end users is the DOE National Test Beds. These are quantum computers at Sandia National Labs — that’s a trapped-ion computer. And the Advanced Quantum Testbed at Berkeley — that’s superconducting. We also have very sophisticated compilers for their devices. One of the cool things on those platforms is, they allow very low-level access where researchers and application developers can almost touch the guts of the quantum computer and our stack optimises to those internal mechanics of the machines. There are a bunch out there. The ones I mentioned are ones where we’ve done last-mile optimisation that ends up raising performance quite a bit.

A good one to start with is probably IBM, because people were more familiar with Qiskit and you’ve done so much on those machines. Do you expect that this type of approach will scale with other technologies going forward — the brand-new IonQ or something? Do you think you’ll be able to find gains in all those types of systems?

Pretty much any gate-based quantum computer is going to have the same device physics properties that our stack is now configured to be able to read in the underlying device physics and optimise for that. Of course, there are other technologies out there that are very exciting — quantum annealing, continuous variable photonic quantum computing. We don’t have a compiler for them. We have some thoughts on applications, but that’s not the focus of SuperStaq.

We talked about the demo and the performance numbers. Can you categorise, let’s say, a typical boost with IBM? Can you give a good example of what that range is for some basic approaches?

I’ll start small, and it’ll sound trivial, but I’ll explain why it ends up building up quite a bit. We have the record right now for the best swap gate — that is exchanging the positions of two qubits on IBM hardware. Essentially, using these techniques, we’ve developed a swap gate that’s something like 17% faster and has 15% less error than the otherwise best swap gate that’s used.

That sounds small, but the thing to keep in mind is that this is a multiplicatively compounding effect where if you have 10 swap gates, you’ve got disadvantage occurring 10 times over. In practice, for superconducting systems that have sparse connections, you need to do a large number of swaps. In fact, swaps are overwhelmingly the only thing you do — more than 50% of operations you do.

What this technology builds up to, along with these dynamical decoupling sequences I mentioned earlier, is that in applications, you see routinely 10x to 100x advantages, and it scales with the size of the problem. If you run a three-qubit circuit, SuperStaq is not going to deliver any game-changing results. But when we did the demo, for instance, we were looking at something like quantum-phase estimation, which is a benchmark and building block of a number of quantum algorithms. And there, at the seven- or eight-qubit scale, we were starting to see huge differences where with previous technologies like Qiskit optimisation level three, you wash out any signal — it’s just noise. With SuperStaq, you get more than a 10x advantage in a measure called KL divergence, which is, how close am I to the correct probability distribution?

Again, this continues to scale up. When you get to the 100-qubit regime and beyond, we expect to see continuing compounding exponentially of this effect, and therefore, it’s hard to assess what the number of the gain is because on small programmes, you get 5x and 10x advantages. On big programmes, you can get 1,000,000x advantages. We like to think of it as, more broadly ,bringing the future of quantum computing sooner.

That’s powerful because what we’ve realised is, there’s a lot of demand for things that work right now, and there’s a lot of hope for quantum-inspired technologies I’m excited about your work on. The reason we are doing quantum-inspired today, of course, is, it runs today, but we’re all going to be happy as an industry as a whole if quantum can actually solve real problems next year or the year after. We just want to make that happen sooner.

Like I said, with quantum-inspired, that’s what we’re trying to do now. But how amazing if we find just that right use case that seemed like it was teetering on the edge and, all of a sudden, it’s viable today, especially if you can go to the thousands or higher x performance boosts. Some of them are eerily close at times for something you could work with. I want to highlight that this might be a way that we shorten that timeline to that first use case that’s not a toy problem. That term is thrown around a lot, and it’s almost annoying. It’s almost as annoying as stepping on a Lego, hearing “toy problem” all the time. We’re on the right track here, so it’s pretty exciting stuff.

When you get in there, though, if you’re new to it and you’re not sure what to do, there are three sample applications you can dive right into. Can you talk about those to give a sense of what’s already been hammered out as things people could get running with right away?

One of the big pushes for this launch was having excellent documentation, which I have to say is something engineers, often including myself, forget about the value of until we see users getting started. It’s something that makes a big difference. During the alpha period, I’d say, our documentation was a bit lackluster. Now we’ve gotten design help. We’ve gotten a lot of internal team reviews on what sort of documentation we want.

Our product manager, Stephanie, has done a great job of curating a collection of tutorials. There are tutorials we have that are open-source, and that includes running things like the Bernstein-Vazirani algorithm on hardware to get better results. It includes things like compiling to hardware that has unusual or nontraditional gate sets. It’s not unlike in classical computing, where there’s always been this risk-versus-CISC trade-off: Is your instruction set complex, which is CISC, or is it small and reduced, which is risk? We can, in our compiler, enable talking to a large number of hardware platforms that have very diverging gate sets all at once. Some of this documentation goes over that as well.

One of the other things is, there are the tutorial notebooks, but especially now, with integrations like Copilot, it also matters to have great function documentation: Is every class and every method well-characterised and well-documented? That was not necessarily in the tutorial. But when you get started to use all this stuff, can a user go into some code that’s not been explicitly covered in a tutorial and actually run it and understand what’s going on? We’re hitting the mark there now that we’re in open beta.

I can touch on tone of the cool things one of our early users did, which blew us away. One of our customers at Argonne National Lab got some of the early licenses to SuperStaq, and there’s a gate called the Toffoli gate in quantum computing. It takes two inputs and reports back if both of them are true. But it does this in a reversible quantum mechanical manner, so it also copies the inputs over. This is something that’s hard to decompose, especially if you have a limited connectivity device. There are some textbook decompositions, and they bottom out at a performance that’s just not that impressive.

Our user at Argonne devised a better decomposition of this fundamental gate using SuperStaq and using lower-level access to the primitives available on IBM. Nowadays, this is built in in a format that any user can run without thinking through the device physics of, what is the IBM superconductive qubit doing? But this was enabled by this researcher who used SuperStaq to draw pulse schedules that are very analog and very unconventional. But building up that, he produced this awesome result and benchmarked it with something called quantum process tomography, which is one of the gold standards for “Is this gate doing better than the one I had before?” and saw a substantial improvement.

That is maybe the most advanced tutorial we have out there, because it’s an academic paper that was just published on September 28 in ACM Transactions on Quantum. There’s a whole spectrum. There’s the easy stuff to get started on, and then there are researchers like the Argonne, Berkeley Lab, Sandia Labs, that are using the software to push the frontiers of what their quantum systems can do.

There’s a mechanism for people who start to play around with this and get good results to feed back in to the community.

There is, and we maintain a Slack workspace where we have had 24/7 conversations with some of our early users who are getting their feet wet. Their input is amazing for us, too. That’s why we are still calling this a beta stage, because the user input is going to feed back into our product at a time scale of hours and minutes, not months and quarters.

Some of this, I’m assuming, feeds back in also as bugs or features that are more built-in rather than things you have to recreate with some kind of tutorial — ways the software will behave better behind the scenes without even thinking about it.

That’s right. Behind the scenes, we’re running this project board that keeps track of any performance regressions or issues noticed by users and have this agile methodology for reacting to them.

Do you know of any applications that are almost ready to be released that you want to talk about now to get people interested in them? Or are there things they can be expecting soon that aren’t there now?

We have a tutorial notebook out right now, but I’ll use this opportunity to talk more about it and get people interested. We put out a paper last year called Supercheq. Supercheq is essentially a quantum protocol we developed for fingerprinting data. Let’s say Konstantinos and I both have season six of Game of Thrones on Blu-ray or whatever, and we want to make sure we have the same data. Perhaps I’m worried that mine got corrupted when I walked home with it in the rain. I could send that entire Blu-ray file to Konstantinos over the internet, but that’s a huge amount of data. It will take minutes, if not hours, to transmit to the point where it’s almost faster to mail it to Konstantinos. In fact, this is what Amazon Web Services does for very large data sets that need to be transferred.

But Supercheq is this quantum protocol that’s built into SuperStaq where a user can check if two classical files are equal by effectively compressing the files into a very small number of qubits. If you have a 100-gigabyte file, you can compress it into a few dozen qubits. This is something that’s now integrated with our stack. I’m looking forward to some potential user trying it out on real hardware. We’ve done some initial tests, but it can be done on any hardware platform. That would be one of the new frontiers I anticipate developing more.

I’ll give a spoiler alert: We’re going to have a version two of our paper coming out quite soon that shows exponential advantages over the best possible protocols while maintaining this incrementality property. Maybe that’s too into the details, but it’s exciting and has caught a lot of attention. We just demoed it to the Australian Army in Perth. One of our team members, Kate Smith, went over there to show it. That’s very front and center on what users are able to do today that is at the cutting edge.

Looking a couple of months down the road, I expect we’ll see some nice results on some quantum machine learning algorithms. Something called the swap test is pretty cool. That’s where you can check if two quantum-state vectors are similar and quantify how similar they are. That’s a quantum circuit that one of our users has been benchmarking and has some pretty exciting results for. I expect to see community-driven tutorials as well. Again, the tutorials are open-source with the documentation, so we think there will be a lot of users who jump on.

Of course, this is for if you’re looking for inspiration, new things to try. But there might be code you’re running right now that you just want to see if you can make it run 10 times better or more. That’s super eye-opening if anyone gets that to work.

Yes. I’ll also put a plug in here for work we’ve been chatting with you and Protiviti about, which is on some financial applications for, let’s say, credit card fraud detection. We’ve been partnering and thinking about how we can help out customers who are looking for quantum models there. That would be another exciting space where, let’s say, some credit card company is going to have, or a financial firm might be able to come up with, the basics of a quantum circuit for running proof of concept. But if they’re in a position where the first iteration is going to get washed out by noise, I’d love it if they can do, like, two lines of code, import SuperStaq, run through SuperStaq and get great results thereafter. That’s where I’m hoping some of this will play out.

Especially if there are some hard edge cases or something that classical is struggling with. The other work we did, we were able to show some pretty big boosts in using a digital annealer, for example, in some cases with the F1 scores and things. That’s definitely one way to go. I encourage listeners who are working on whatever right now to consider that this might be a game changer and to definitely get involved.

Of course, in the show notes, we’re going to have a link to the docs, and from there, you could click and try out the software. Is there anything they need to know about trying out software? What considerations do they have to have in mind for getting an account?

It’s pretty seamless. The front end, the client, is open-source. You can check it out with an Apache License. If you’re wondering what is the business model here, we have limited usage for the free trials, and, of course, that’s because we protect some of our proprietary techniques that are patented in the server. What the sign-up enables users to do is get free credit to access the server — no time limit. But if someone is going to run 100,000 calls to our server, we want to make sure we’re prepared to support that.

That’s the business model, but it’s pretty seamless to get started, run several circuits on IBM, several circuits on the Amazon Web Services back ends, several circuits on a number of other devices that we support. The fact that the front end is open-source helps make it transparent as to what we’re doing.

The other thing we made a concerted effort to do is, similarly, in the spirit of transparency, have as much visibility for the user as possible in terms of what is going on behind the scenes. Again, many users, if not the vast majority, won’t care about “What are the pulses operating this?” But for the users, especially from a research community, who want to know what is going on behind the scenes, we make sure we show what is happening when you press Run. What are the pulses that are running. What is the gate representation of each pulse? What are the air parameters? We make measurement air mitigation optional. This is a technique that is powerful, but it also can sometimes obfuscate results.

Rest assured, for any interested listener, that you’ll have a lot of knobs to play with. There will be defaults that are easy to get started with, but you can often turn off the defaults if you want more and more visibility into the process that’s underlying.

And if you’re not super technical and you’re interested in having someone help you with a quantum project, we would be able to show you before and after — how much better a use case will run. It’ll be exciting to see what we come up with going forward. Thanks so much for making this available to anyone who wants to experiment with it and for coming on here to let the world know about this.

Absolutely. One question I have for you is, having seen the whole quantum landscape, what are you excited about for, let’s say, quantum software, hardware, that I’ll take as feedback as well to internalise to future iterations of SuperStaq, and perhaps ones that might be on your mind right now that you want your listeners to hear about?

I definitely want to see the ability to boost performance greatly because we’ve been so hampered still. It feels like we’re stuck with machines just ever so slightly getting better. I’m excited right now to see how an approach like this would be affecting everything across the board — all the stuff we’ve been doing for the past couple of years: Give it a fresh look, a fresh set of eyes. I’m excited to try this against almost everything for that approach. Also, is there anything like this that can be done for the world of annealing? Is there a way to shift over?

We have some thoughts in that direction — nothing product-ready, but one of the things I’ll observe is, there isn’t necessarily as much of a distinction between gate model and annealing as there needs to be in the sense that quantum annealing is an analog process. What we talk about as gates is, under the hood, an analog process. One of our researchers at a national lab who spoke with us recently is interested in seeing if they can use SuperStaq to perform quantum annealing on traditionally gate-based devices. Imagine if you could use IBM’s 1,000-qubit machine and intersperse with gates, but between, you’ve got an annealing protocol, so you get, potentially, the best of both worlds. That would be exciting. We don’t have that yet today, but that could be cool to see.

Or can this be applied to the whole analog mode of machines like QuEra or something like that?

Definitely.

We’ll have you back on when you succeed with that. Or we might have you back on if we succeed at a few other things we’re working on right now. Once again, my friend, thanks for coming on, and good luck with this new launch.

As always, I appreciate your time, and thanks for having me on.

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. SuperStaq is an optimising platform for running programmes on current quantum hardware. Before sending your code to, say, an IBM system, you pass it through SuperStaq, where it will be optimised to run on that hardware and will return up to orders of magnitude better performance. The software works with other hardware too, such as systems on Braket, Rigetti and even DOE National Test Beds.

How does it work? Some of the techniques used have been around for a while, such as removing redundant gates. However, SuperStaq goes much further, including understanding the device physics involved in specific systems. As a result, the software can even handle some of the noise that enters an execution, especially as more qubits are used in a circuit. SuperStaq can use dynamic decoupling to extend coherence times, where it adds extra gates to protect qubits from noise. Noise accumulates in one direction for half an operation and the other direction for the other half, for example, canceling out.

The software also makes improvements to swap gates, which are the most common operation in a circuit. Adding up lots of faster swap gates and reducing noise using dynamic decoupling can yield stunning results. SuperStaq routinely improves performance by 10x to 100x, but in some cases, with very large programmes, Pranav says, SuperStaq should be able to improve performance in the 1,000,000x range. These are the kinds of boosts that could make NISQ computing provide real types of advantage today, before we get fully error-corrected qubits.

It will be exciting to see the results over the next year or two of experimenting with this — and lots of companies are already experimenting with this. If you’d like to join in, check out the link in the show notes to read more about SuperStaq and sign up for access. There are tutorials and sample code to get you started.

That does it for this episode. Thanks to Pranav Gokhale for joining to discuss SuperStaq and Infleqtion, 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 find 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 Protiviti Tech on Twitter and LinkedIn. Until next time, be kind, and stay quantum-curious.