Quantum Computing at Rigetti with David Rivas

23:57So there's a translation layer there. And that's where sort of an instruction set architecture becomes important because you need to define what instructions you can operate. Similarly, you need to know how to construct the pulses associated with those gates because those things are highly tuned operations. And there isn't only one way to do it. There's many, many ways to do it. And an awful lot of work gets done on any given quantum computer in defining those gates and building them in such a way that they can help mitigate errors and otherwise be most efficiently run. So there's a translation step that takes place once you've got that native gate set to turn it into what is essentially that schedule that we're doing.

24:32Yeah, it very much is just sounding like a classical compilation pipeline where you're lowering it bit by bit. So you've lowered it from the sort of set of transformations on the full logical set of gates to now it's the set of transformations on the gates supported by this computer. And then you lower it down into the pulsing schedule and kind of take it through these phases. There is some fabulous work being done right now in the LLVM community in terms of building out various abstractions that can be leveraged so that we can build some better general purpose compiling tools for quantum computing.

25:07Just to take that idea a step farther, if you think about what I said earlier is you've got a classical computer program that's being written that's then going to write quantum instructions. And you can imagine a single compiler taking all of that and building the appropriate execution artifacts that then get properly scheduled in the environment. And I suspect, well, I know some of that is actually happening in some places, and I suspect we'll be seeing a whole lot more of that. Right now, it is a little bit less efficient than that in terms of the tool chain that's involved. Like, for example, we have separate tools that produce those compilations, and we actually tend to run them as services so the application can determine when it wants the compilation to take place for efficiency purposes.

25:47Got it. That makes sense. So if we talk briefly about like that highest level, but still quantum programming interface, think that as I understand it is the Quill programming language? We have two languages that share the name Quill. One is called PyQuill and the other is Quill. You can think of Quill as our assembly language programming environment. So this is the thing that takes basic gate level descriptions and you can produce a schedule directly from. It turns out that like in the early days of machines that implemented a microcode, there is value in actually programming at that pulse level, they call it.

26:24Again, if you squint, kind of like a microcode. And we have something called an element of Quill is a tool that allows you to also program in the pulse level as well. And then PyQuill is really a binding to a set of Quill operations. And it's not really a compilation tool chain as much as an interpretive environment written in Python that allows you to produce Quill programs and then execute those programs. And in our environment, there's a collection. Since it's involving execution and the coordination of all of those resources that I just described, you're really talking about something that has a SDK.

26:59so the PyQuil thing is built upon CRUST SDK that then provides you not only with the tooling to do the translation necessary but the tooling to do the execution elements of this as well and the scheduling and all the rest that you want to do yeah this makes sense so at this point I think we're talking like at the level that a programmer would be engaging with it today it still feels like a very like if I compare to classical computing it's a very low level of abstraction We're still essentially writing assembly code equivalents. Is that a fair assessment? I happen to think so. I think we have yet to see the explosion in programming languages that we're going to see for quantum computing once the systems get to the point where they're actually doing the work that we think they're capable of doing.

27:44I used to talk about the sort of expectation of this Cambrian explosion of languages because this is what happened in the early days of classical computing. We had this huge explosion of interesting ways. And that hasn't stopped. And I suspect that's going to be true for quantum computing, but not quite yet. Let's maybe talk a little bit about those applications and what you think the thresholds are to be able to start unlocking those. So what are you seeing as the core application areas where quantum computing is going to be? Yep. This is a pretty standard list you'll see out there in the industry.

28:13We have direct experience with working on certain enhancements to machine learning algorithms, as well as preparation of data for classical machine learning algorithms that are starting to produce some interesting results. The idea here is that one of the things that's true about a quantum computer is that it's effectively a stochastic machine. And that means that you can actually do things like produce unique distributions from them. And in fact, one of the things that we're finding is that leveraging machine learning techniques, you're beginning to be able to model particular distributions that enable you to do things like produce what looks like random data, but modeled to a particular distribution.

28:52This has all kinds of use in terms of training for machine learning algorithms. You can think of rare event detection as a classic problem here. There's a whole bunch of things that you'd like to be able to have lots and lots of data for, but you don't. But if you can actually model the distribution and generate the data that way, well, then you can train a traditional classical machine learning model. So that's one big class of things that we're expecting to see. Another class of things is in optimization. As I said, it's a well-studied problem. There remains an open debate about will a quantum computer actually ever beat a classical optimizer?

29:24The longer answer probably goes like this. We believe that we can certainly run larger optimization problems than classical computers can in the general sense. What seems to be true, at least in the classical case, is that every time you come up with a good optimization algorithm in quantum, some clever chap goes off and goes, oh, you know, if I just tweak my classical optimizer like this, right, you start applying serious heuristics to the problem and you get a reasonable solution. That's great. I mean, that's how these things work. Like I said, there's still some intuition there. I'm going to hold that thought, talk about one more thing, and I want to come back to this.

30:03The other thing is, and I hinted this earlier, is there's a whole collection of problems that involve modeling quantum processes. And there's an expectation that, especially as we get to the higher cubic counts, we'll be in a position to do some of that modeling very, very well as well. And here's the thought that I wanted to sort of make sure that we talked a little bit about. We are currently building systems. Our largest system to date is 84 qubits. And it's not quite performing. There's a metric that is used out there called the two qubit gate fidelity. And this is like one minus the error rate of the two qubit gates.

30:40The reason we need an error-corrected system at some point is so that we can dial that number as low as possible. But that's going to take a lot of physical qubits, more than 84, to get a 50 or 60 qubit or 100 qubit system. But we're getting pretty close. We're at about, you know, at a half a percent. We expect to get down to a percent of error over a period of time. And what I'd like to make is that, you know, once we get to, I don't know, 500 or 1 ,000 or 1 ,500 physical qubits, sort of at that 1 % or lower error rate, so, you know, 99.9 or maybe 99.99. level of fidelity, we have in our hands a computational resource that is not simulable by a classical computer and is more capable than we've ever seen before on some metrics.

31:29And so, you know, there's this question of, well, what's going to happen with that system? And the short answer is we don't know. It's a little bit like what happened when von Neumann and friends found the ENIAC, right? They went, wow, 20 ,000 multiplies? What can I do with 20 ,000 multiplies? That's huge. Well, it's more concern than von Neumann invented Monte Carlo methods with that, right? So I suspect we're going to have a moment like that at some point with systems prior to full fault tolerance and full error correction. Where that's going to rear its head, I don't know the answer to that yet.

32:02But that's sort of the beauty and joy of working in this field right now is you're building this resource that really does have tremendous promise associated with it. And we're not quite yet sure where it's going to find its first true serious applications. Question about those sort of scaling pieces, because you said something that tickled something for me. You mentioned, okay, at that point, you're able to address problems at a scale beyond anything a classical problem can do. But I'm also thinking there's like multiple directions that problems scale. And one of the big things that so many folks are tackling right now is just scale of data.

32:35Data is scaling. How much data can you feed into one of these systems or get out of it? Like, is that dimension of scale there? Or are we talking other dimensions? It's a great question. And the short answer is, at least for the systems that we have at hand today, these are not suitable for pumping terabytes of machine learning-like data through them. On the other hand, what they are suitable for is setting up models that require in-memory or near-in-memory representation of very large amounts of data. So this is a complex system where you need a lot of state to represent that system. And that's something that, you know, we've never had systems that can do that.

33:14So, you know, where that's really going to get applied is unknown. But again, I think it speaks to the kinds of things we expect to do with physical system modeling that we haven't been able to do other than with, you know, wild approximations in our classical numerical algorithms. I suspect that's a place that will bear a lot of fruit. Got it. So if I were to restate that a little bit, handling large amounts of data flow is not their strength. But being able to make sort of quick operations on a very large stateful data that you might have to load into memory or something like that, that is where we think these can reach a new dimension.

33:50Certainly based on the architectures that we have and the way we express quantum computing, that feels right. Okay. That makes sense. Let's talk a little bit about the classical software around this. One of the things that I thought was really interesting when I started looking into Rigetti is that I can run stuff for you just on Microsoft Azure. How are you thinking about all of the ecosystem of software around the quantum computer itself? Right. Well, you heard what I was describing before for the basic execution chain and the compilation tools and all of that. And we've had that for some time.

34:26We were also among the first, in fact, we were the first organization to not just put an API up that says, you know, talk over the internet to our quantum computer, but we built out a system that effectively provided you with what was then a VM and then quickly moved to containers to execute classical hybrid programs in an environment where the connectivity between the classical program and the quantum processor itself was very, very low-light, so giving you relatively pretty high performance. Building that software leveraged most of the tools that I just described, as well as the requirements to build out infrastructure to support that high-speed connection to the quantum computer from the classical computer.

35:07We leveraged all of that when we moved. First, we moved to AWS. We were a flagship launch partner with AWS when they had their bracket system. And then not too long after that, we were up on Azure as well. And the important thing, at least for us, is to try and both dog food the systems that we're building, but also make them as scalable as possible. So it is the same. We call it quantum cloud services. It is the same software that we use to run our own cloud system, that we use to run and operate our computers here. So when we're doing bring-ups, when we're making new machines and getting them first alive, it's the same software that we use to integrate into Amazon and Azure.

35:46The considerations between those two kinds of environments have a lot to do with security issues. You don't get into Amazon without being very, very secure, and they are quite serious about that, as well as performance issues, things like latency and such. At that point, it's not so different from being here inside Rigetti running an application. They're going to get closer and closer every year as everybody works on the efficiency issues. Get close to answering what you were looking for? Yeah, well, and I'm kind of curious then, how do you see people utilizing quantum computing going forward?

36:21Is it the same, like, is it you spin up an AWS instance and you hand it off to a service the same way you might to a DynamoDB or something like that? You're like, all right, just go run this on Rigetti. That will certainly be a part of the mix of things. Because of the nature of the kinds of problems that we expect to be working on, some of this will involve highly classified data. There will be the necessity for on-prem systems for sure. At this stage of the game, the market is pretty bifurcated. There is a group of folks who use cloud-based quantum computing in research applications that are predominantly software-based, as well as there's an awful lot of learning that's going on.

37:00You know, the first interactions that most people have with a quantum computer are usually through one of those cloud services. But there's a whole bunch of work being done now to build out ecosystems around national quantum computing centers and research laboratories, the national laboratories. And so on-prem systems are becoming an important element of that. And in fact, one of the things we're finding is that governments are taking a serious interest, generally speaking, in quantum computing. And so funding is coming from a variety of governments to support the extension of supercomputing environments.

37:30And I'll talk about that in a second, as well as just general national quantum computing centers are being set up. We recently launched a system, the UK's National Quantum Computing Center outside of London. We have systems at Fermilab, at the Air Force Research Lab. And then we provide this cloud quantum computing systems to our DoD partners and others, you know, all the time. Like I said, we run our own cloud system, you know, in a pretty high performance way. There is a really interesting, we're in an interesting time from a supercomputing perspective as well. So Exascale has been reached in supercomputing, right?

38:03ORNL has produced two, you know, very, very important systems in the last five or six years. And, you know, there's a lot of discussion. I think you were hinting at this before. There's a lot of discussion about the varied hybrid modes of classical computation. And you can extend that to treating quantum computation as an extension of the toolkit, of the palette that you have within which to build a computing system. And so as the funding cycles associated with supercomputing start to look towards that next five or 10-year system, there's a lot of interest and energy being spent on integrating quantum computers into that.

38:36In fact, we did an integration of our Onca2 system with ORNL not that long ago, sort of over a network connection. The idea is to just, okay, so what's this going to look like? How do we hook these things up? Yeah, it's kind of a wild thing. So I think this is a good opportunity to sort of step back and look at kind of where these things are in their sort of evolution of use and what you see the timelines and milestones coming down the pike looking like. It's a very dangerous and not very rewarding thing to predict quantum computing. But I'll say this, and I'll lean back on something that I said earlier.

39:14Look, the way this works, the way technology generally works, is you build to what you have and you just keep improving it. And that's what we've been doing for some time now. We're about to reach a threshold where we're going to put a computational resource in someone's hands that they've never seen before, the power of which they've never actually had. And at that point, we should expect to see something interesting pop out of that. What it is, I don't know. But our roadmap clearly states, you know, we'll give you more than 100 qubits by the end of the year. You know, I suspect that'll be more than 100 qubits not long after that.

39:49We're pretty clear, you know, that in a couple of years, 1 ,000 qubits is right there. 1 ,000 physical qubits at very high fidelities, that's a big deal. You go farther out, the numbers start to look like 2030, 2032 before we start getting proper fault-tolerant error-corrected systems. That's what many people are betting on. The Department of Defense, DARPA, recently put out a bid for people to build systems that roughly in that timeframe would be fully fault-tolerant. We actually were quite proud. We're engaged with that thing now. But that's different from saying, oh, well, we'll reach quantum advantage in 20XY.

40:26X, Y? I don't know the answer to that question. And honestly, I don't think anybody really does. The game right now is to build the best possible systems. And you see a few people doing that right now. And the thing that has surprised everybody in the last three or four years is just how fast that's come. We were scaling our systems from a qubit count pretty aggressively two or three years ago. We had 80 qubit count systems up on Amazon and we're still at 84. Part of the reason we're still at 84 is that we focused on getting the fidelities up. So I've been having our error rates less than every year or so.

40:57And that's a really good trajectory for us beyond. So I said, we'll crank the scaling back up. Interesting thing about that in terms of techniques for scaling. So we're unique in the industry. We're about not to be unique in the industry, but we're unique in the industry in building quantum computers out of multiple chips. So that 80 qubit system that I was telling you about, it was on Amazon two and a half years ago, was built out of two 40 qubit chips. And these weren't chips operating separately. We got entanglement across the chip boundaries, which is the thing that you want. This is a grid of qubits locked together, and the chip-to-chip boundary had entanglement across neighboring qubits.

41:37We announced we'll build a 36-q system out of 9-qubit chips sometime in late spring, early summer of this year. And we'll certainly scale for anything above 100 qubits. Those 84-qubit chips are about where we want to stick when it comes to the size of the chiplet that we use. Now, IBM is starting to do that, and others are definitely going to come along. But it's an important thing to note, that that's how scaling is going to happen. Yeah, that's wild that you can get them entangled across chips. And the performance is as good as... That's where I was going to ask, is like, do you get the same error rates and things?

42:08We do. We were even a little surprised. I mean, the theorists were going, no, we got this, right? We modeled it. It's going to be fine. But when it actually happened, people were like, look at that. It really did what we thought it was going to do there. It was a big deal, actually. We were pretty proud of that. And it was kind of lost on the industry at the time, I think. But we're bringing it back. What does it look like? So you mentioned you're a full stack company. And a lot of the stuff we're talking about in milestones here are kind of manufacturing level almost, right? They're like, okay, we're going to improve this process.

42:34We're going to improve this error rate. What does the software organization inside of Righetti look like? How are you organized? And how does that interact with the hardware pieces? Well, that's a great question. I'm so glad you asked that question. It's lost how much software is required to actually build a quantum computer. So we have two organizations. One is the QCS software organization. They're really responsible for that operating environment that I just described to you, compiler technology, the execution pipeline, the interface to the control system itself. There is a whole other internal software organization that is responsible for building the tools that we use to bring up, measure, characterize, and otherwise manipulate the machine itself.

43:16So I was telling you before that when you define a two-qubit gate operation, you have to define the very specific microwave pulses that you're sending down to those two qubits. That's a combination of science and art at this point involving error mitigation techniques and such. And you need quite a lot of software to support the efficient experimentation of that. So our measurement and characterization software, it's something we call Treeline, has been a major effort for us and has been the thing that has allowed us to reduce, most recently in particular, to reduce those error rates as fast as we have, because some of it is just pure gate manipulation and mitigation techniques.

43:50If you think about it, one little bit of information. So there's a collection of operating points for each of those qubits, the frequency of the qubits, some aspects of the pulses that you need to define, kind of part of the instruction set architecture, if you will. And that manipulation or the definition of those parameters is an iterative task that is effectively an optimization problem that you have to perform. You know, at 20 qubits or 40 qubits or frankly, even 80 qubits, it's vaguely manageable. At 80 qubits, it's not so manageable, but it's vaguely manageable. At 500 qubits, there's no other way but extremely efficient automation.

44:29And the expectation is the optimization is complex enough that applying machine learning to that optimization is going to be necessary to get anywhere at all. And we've done a little bit of that already. So those tools are very, very important. FAB is producing data all day long, right? One sort of very glib characterization of what a FAB does is take a specification and then produce yield of chips for us, right? And in order to do that well at all requires a tremendous amount of experimentation and data collecting and an analysis of that data. So we have that internal software team leverages that as well.

45:02But as I said earlier, fortunately, we live in an age where we're 80 years old with software technology and open source technology and networking technology and high performance classical computing technology. So all of that is being brought to bear on solving these problems. Right. We've got Kafka pipelines now set up to do the collection of all that data so we can real time integrate it with the systems that we're using. We can produce analysis and monitoring tools on that stuff to see where we are. the optimization thing that I was telling you about that has to happen to bring the system into being has to recur a bit because these systems drift from time to time.

45:35So there's a whole process to do what we call retune with these things. It has to happen from time to time. And we're getting to the point where more and more of that will proactively retune rather than schedule some time to go do the retune based on streams of data coming out of the systems themselves. So a lot of modern software development going on here as well. And I guess I should say it should be taken as read that all of this is deployed in modern container and architectures. We can put it on-prem. We can put it in the cloud. We put a lot of it in the cloud already. We're leveraging all that technology.

46:04Yeah. Well, and I think a theme that I've definitely been seeing recently is it feels like in recent years, we've hit sort of thresholds from a software and machine learning perspective that are opening all sorts of doors in hard tech and sciences and other different things that we're just starting to see the impacts of. Now, looking at your systems, and you alluded to, or you mentioned earlier, one of the possible application domains where quantum computing has an edge is in modeling quantum phenomenon. Are you using your own systems to help model or design next generations of those systems, or are we not at the bootstrapping phase yet?

46:45We're not quite at the bootstrapping phase yet. That's actually, I hadn't thought of that in these terms before, but that's a milestone that will be worth celebrating. And when people talk about using quantum computers and the utility associated with them, there's utility now because obviously people are buying and using, but to be fair, it's a lot about exploring quantum computing and the system building associated with it. But the minute we start bootstrapping and there's optimization problems all over the place, that will be very, very exciting for everybody involved. Care to wager a guess how far off it is?

47:14I'm not going to do it. Soon, I hope. We've talked about quite a range of interesting things. We're getting close to the end of our time. Is there anything we haven't talked about yet that you think would be valuable to go into? There's a couple of things that come to mind. One is this. The quantum computing starts as a very scientific endeavor. And there's a double-edged sword to that. On the plus side, we're so close to the science still. There's a kind of openness in this community that's exciting. People publish on the archive all the time their results. Even though there's significant competition in the industry right now, there's sort of a joy and a beauty associated with going, oh, look what they did, and learning from each other.

47:57And, you know, the fact that it is so scientific. You know, the big conference is the American Physical Society Conference in March. And, you know, everybody's going to be there. We're all going to talk about their results. And that's really quite wonderful. It's different from going to any of the traditional computing conferences that I've been to in the past. It also seeps into the work itself. You know, nobody is here that doesn't really, really want to build this machine, right? That's what people are doing. They're like, the story I often tell people is when I came back from the first interview, I was talking to my family and blah, blah, blah.

48:30I was like, Dad, are you going to do this? I'm like, dude, they're building the ENIAC. I regret it the rest of my life. I don't do this. It's kind of true. That's the feeling you get when you're doing this work. And that's a lot of fun, right? The other side of it, because it's so academic, is sometimes people forget we're building a computer. and that means integration and speed and lots of classical quantum computing. I can't tell you how many times we'll be putting a bomb together for a system that we need and somebody forgets to spec the classical computers that need to go in the rack, right?

48:58That's actually not happening anymore, but that was the kind of thing that used to happen or, oh, what about all that software that has to happen? Because it's a bunch of physicists building this very, very difficult thing. One of the things that I'm quite proud of for Getty doing is expanding the footprint of the team here to include proper professional software development teams, proper infrastructure teams, right? Teams that are capable of bringing the best practices from all over the place to bear on this. Yeah, we write a lot of Python and that's a very useful thing to do. A lot of our system stuff is being done in Rust now by people who know what they're doing.

49:32And that's also a useful thing to do. Well, and Python written by a software engineer with experience looks very different than Python written by a grad student who's doing this to try to get their results. Hear, hear, hear, hear. And in fact, that's exactly what's been happening. And one of the great things to have watched over the last few years is folks that started off, you know, sort of as those grad students now being very qualified professional software engineers here. So that's nice as well. Yeah, that's awesome. Well, this has been super fun. I'm glad you enjoyed it. I did too.

50:12Thank you.