Computer Architecture Podcast - Ep 6: Quantum Computing Architectures with Dr. Fred Chong, University of Chicago

Episode Date: August 30, 2021

Dr. Fred Chong is the Seymour Goodman Professor in the Department of Computer Science at the University of Chicago, and the chief scientist of SuperTech, a quantum software startup. He is also Lead Principal Investigator for the EPiQC Project, an NSF Expedition in Computing. Previously, Fred received his Ph.D. from MIT in 1996 and was a faculty member at UC Davis and UC Santa Barbara. Fred has made significant contributions to architecture and system stack for quantum computing, and his other research interests include emerging technologies for computing, multicore and embedded architectures, computer security, and sustainable computing.

Hi, and welcome to the Computer Architecture Podcast, a show that brings you closer to cutting-edge work in computer architecture and the remarkable people behind it. We are your hosts. I'm Suvainai Subramanian. And I'm Lisa Xu. Today we have with us Professor Fred Chong, who is the Seymour Goodman Professor in the Department of Computer Science at the University of Chicago, and also the Chief Scientist of SuperTech, a quantum software startup. He is also lead principal investigator for the EPIC project, which is an NSF expedition in computing. And previously, Fred received his PhD from MIT in 1996 and was a faculty member at UC Davis and UC Santa Barbara.

Fred has made significant contributions to architecture and the systems stack for quantum computing. And his other research interests include emerging technologies for computing, multi-core and embedded architectures, computer security, and sustainable computing. Today, he's here to talk to us about the system stack for quantum computing. A quick disclaimer that all views shared on the show are the opinions of individuals and do not reflect the views of the organizations they work for. Fred, welcome to the podcast. We're so happy to have you. So let's kick it off with something generic and broad. What is getting you up in the mornings these days?

I mean, broadly speaking, the thing that excites me the most are my students. And also, you know, more specifically, you know, the specific work that we're doing in quantum computation is really sort of at a really historic time. And so, you know, student-wise, I just had my first five PhD students graduate from this crop at UChicago in the quantum space.

And they are just taking their first jobs. One is starting at Yale as assistant professor. Several went to companies, Intel, Amazon, and HRL. And then one founded our startup company, Supertech. Right. So quantum computing is, of course, one of those paradigms that promises exponentially greater computing power as you scale the number of devices and so on. But before we sort of dive into the technical details, could you maybe paint a broad picture

of the landscape of quantum computing for our audience? How is it different from classical computing? What really the only technology that we know where, you know, adding a single device to a computational system doubles its computational power, right? So it's the only sort of exponentially, truly exponentially scaling technology that we have. And so as such, it's the only approach that we have to try to solve some of the intractable exponential scaling problems that we have in computer science. Now, of course, it only applies to certain specific problems in that space. Right. But I think it's very exciting in that way. You know, that's how it's different. But I think that, you know, what's really exciting right now at this time is for the first time we have real machines that have been implemented primarily in industry that are of a scale that can't be simulated by classical machines, right? And so for the first time, we are at a cusp of really new science

because the only way we can understand these machines is to do experiments on them. Even more to the point, the algorithms that we want to run on these machines in the near term are heuristics, which we don't have analytically sort of proven performance predictions for. So there's some promise,

and we suspect that there are some substantial performance gains to be had. But the only way we're going to learn about these algorithms and how well they're going to solve problems and how much better they are than classical algorithms is actually to run these on these machines and sort of do the engineering and some of the things we'll talk about today to make them work well and hopefully do something that hasn't been done before and something historic. That sounds awesome. In the particular field of computer architecture,

there's always been this sliver of folks who understand quantum computing and that sliver of folks has not grown by leaps and bounds the way, say, the group of people who understand quantum computing and that sliver of folks has not grown by leaps and bounds the way, say, the group of people who understands ML has grown by leaps and bounds in our field. So when it comes to quantum computing, the thing that you said initially, which was like, you know, you add a single device and everything, the computational power changes exponentially. The three things that I've learned about quantum computing in the past is that they're finicky. And so is it really the case that one device doubles it? I keep hearing about having to have all this redundancy. And so there's this notion that as you expand the number of devices, some of it have to be dedicated to redundancy to make sure that the answer is

correct. So is it truly that exponential? And I've heard that there's different approaches to how you might build the machine and trending towards needing more redundancy versus less. Does that affect the software stack? So I kind of want to hear about this aspect. Absolutely. It is definitely the case

that one of the most challenging things in quantum computation is dealing with errors, right? And part of the difficulty in that is that there is this thing called the no-cloning theorem, which says that you can't perfectly copy an arbitrary quantum state. The implication of that is there's no way to sort of make a backup copy or a checkpoint of your computation. And if you have an error that isn't correctable, you've essentially lost your entire computation. You have to start over, right? And so the approach has been to either in the near term, just run short computations and try to make your machines as reliable as possible, or come up with, as you were mentioning, some sort of error correction

method, which allows you to essentially continuously correct your errors without, there's, you can have redundancy, but you can't have essentially a perfect copy. You have to encode the particular state in a particular error correction code, and then continuously correct it without, you know, essentially have, there's not a notion of backup copy. You just have to keep the data constantly in this correctable state. And then all of your computations are within that code. And so it's true that that kind of redundancy costs you something. But in general, the redundancy is sort of polynomial in overhead, which means that you still can have that exponential gain.

One thing I didn't mention is the other big challenge in quantum computation is there are limited number of algorithms that have potentially an exponential gain. In fact, they're not, it's not a provable exponential gain. It's just in practice an exponential gain, right? Sort of the best known classical algorithms are exponential and the best known quantum algorithms are not, right? And so, but there's no proof that says that we won't come up with the polynomial algorithm for the exponential, in the classical case, right? But it is still the case that as far as we know, there are some exponential gains to be had. And even with error correction, those persist, right? That isn't to say that there's a lot of engineering to be done because there are a lot of constant factors. And

as architects, we know that even though if there's an asymptotic game, it may be that the crossover point isn't anywhere useful in practice, right? The other thing I'll mention is that there's actually sort of a middle ground between the two things I mentioned, which is make machines as reliable as possible physically and then run short programs or error correct them. There's a

middle ground sort of to bridge those two things, something that we call error mitigation techniques, where instead of using a single physical device to implement a quantum bit, we might use some, a couple of them or some ensemble and have a little bit of, it's almost like physical, it's not really error correction, but sort of just a physical ensemble that represents a little bit of, it's almost like physical, it's not really error correction, but sort of just a physical ensemble that represents a qubit that has a lower probability of error. And that's somewhere in the middle of these two things. And that's probably what's going to be next. And then hopefully we'll use that to bootstrap ourselves to some sort of error corrected system. So just picking up on the algorithms, both in the near term and long term. So how should we think about, you know, programs that are amenable to quantum acceleration,

both in these different paradigms in the near term and maybe even in the longer term? I mean, most quantum algorithms, especially in the near term, you could think of as essentially an energy minimization algorithm. You have some system that's represented many times actually just in analog on your quantum device. And then you have a means of minimizing the energy of that system. And that really just reduces to optimization, right? You can think of most quantum kernels as optimizing some hard, small problem that is a sub-problem of something you need to solve in your sort of larger application, right? So you could think of the quantum machine as a quantum processing unit,

or like a QPU, like a GPU, right? And you send it a little piece of your program that you want to accelerate it. A good example would be, for example, something called the variational quantum eigensolver is something that looks for the lowest energy state of a particular sort of molecular compound. And essentially what it's trying to do is it's trying to find the electron positions,

what orbitals they should be in, in that compound to minimize the energy. And the way it actually works is you have a classical outer loop use of supercomputer, which essentially is trying to guess or search for where the electron positions are. And then with each guess, it sends that guess to a QPU, a quantum machine, which will quickly give you an estimate of the energy of that system, right? Or sort of the ground state. And that's actually a very direct analog. You know, you have a quantum system you're trying to model, use a quantum computer to model it.

But another way you can think of it is you can use something similar where the kernel represents an arbitrary graph. And you can set it up so that if you want the max cut of that graph, for example, that can be found essentially by minimizing energy of the system that represents the graph. And so by analog, you can solve a lot of different optimization problems. It's almost like annealing. You're heuristically minimizing the energy with some error. But the idea is that because you're doing this in a quantum sense, it tends to be better at avoiding local minima and more quickly converging to a

sort of more global optimal solution. And at least that's the theory and that's the hope. Right now, I think there's a lot of work in seeing how well such algorithms will work in practice in the presence of noise, because the noise makes it so that maybe you won't find such a good solution or it won't converge a solution as quickly, right? And so there's a lot of work in looking at how good the machines have to be to implement kernels like this that you could sort of see are generally useful for many applications. And when will it be that we get an advantage from these machines? So how would you go about characterizing a quantum machine, right? Both in the presence of these variations or noise and things like that. For example, for classical machines, like GPUs will have like a headline flops number and you say, oh, this machine provides you this many raw flops.

In the quantum computing world, there's always this talk about qubits and the number of gates and things like that. So is that something that you would use to characterize the ability of a machine? And how does that interplay with would use to characterize the ability of a machine and how does that interplay with the noise characteristics of the underlying machine or the underlying technology and the algorithms on top of that? Yeah, that's a very good question, actually. In general, when you look at press releases and the news on quantum machines, you'll basically get qubit count, right?

And that's basically equivalent to characterizing microprocessors by gigahertz, right? By clock speed, which we all know is not actually the performance of those machines. And in fact, qubit count is probably the easiest thing for them to scale, which is of course why people use that to measure the progress of their machines. The harder thing is actually the fidelity of an operation or a gate.

So a two-qubit gate is really the hardest thing right now. And that is actually the limit, the thing that limits our computational power in these systems, that we can only run programs that are so long because the two qubit error rate say, right now it's about one in a hundred, which means you can run a hundred gates and then your system's dead, right? And we could see that it's probably gonna get to one in a thousand.

And I think Google has a goal of getting to one in a hundred thousand, which means we could run a hundred thousand gates in the critical path before the system is done. So that's a very critical parameter. And many times you'll see that the space that the power of machine might be, you can think of it as an area, which is the product of the gate fidelity times the number of gates, or no, the gate fidelity times the number of gates, or no, the gate fidelity times the number of qubits

it supports, because that's like sort of gives you an area of how much computation you can do. IBM actually has a metric called quantum volume, which is a little bit like that, but it's a little bit, it's a lot more complicated and And it looks at the connectivity of the machine. It looks at like by running a particular benchmark, how much can you run? And it lately has become a little bit obsolete because the machines have gotten too good. The quantum volume was sort of deliberately made so it scaled exponentially.

So the numbers got really big really quickly in the beginning. And then as machines got really good lately, the volume went from tens to 100 to a million. It became too big now. So that's probably not a good metric anymore. And so the thing that's happening now is an evolution which is, you know, analogous to classical machines, that we're starting to look at benchmarks,

right? And in fact, a number of companies and places have just starting to actually put together a much more systematic methodology for benchmarking these machines, looking at their different characteristics and creating benchmarks that exercise those different characteristics. Well, so I actually wanted to try and tie that all the way back around to the whole error correction piece that we were talking about in the beginning, right? Because, you know, to some extent, there's different places where this redundancy can be handled, right? So there's like the, you know, what Souvenay was just asking about was like the fundamental nature of the machine, right? So that seems like a machine implementation where it's like the fidelity of your gates. And then you were talking

a little bit earlier about this space where you can have, you know, you, you run only short programs, or maybe you have some of your power dedicated to error correction that, that latter piece where if you, if you know, you're on that other extreme, is that a software artifact or is that a, that seems like the way you just talked about all this stuff, maybe that's a software artifact or is that a hardware artifact? You mean, is the error correction,

do I view that as software or do I view that as hardware? Right. Some of that may be done in hardware in some sense in that it's, so all the software that we produce basically reduces to some sort of control signals. And in fact, with most machines, getting those control signals to the qubits is expensive.

And so you might think of some of the frequently occurring tasks, they might be implemented in some sort of firmware or hardware that's much closer to the machine. Or for example, with superconducting machines, the qubits are at like 20 millikelvin, right? So they're very far in the refrigerator of the machine. And getting control signals to them is very hard. I think Google thinks of it as you might as well have that machine on Mars, right? That it takes so long to get signals to it and you really can't get to it to look at the chip and debug it.

And so this question of whether it's software or hardware, yeah, I think we are starting to, you know, there are groups starting to look at taking some of that, what we would have thought of as software and making it firmware or hardware. You know, Intel has some cryo CMOS implementation of some of the control. I think we're not quite at putting error correction there yet, but I expect that we will. There've been some academic papers on such schemes. So yeah, I would say traditionally we think of it as software, but some of it will become hardware,

possibly not all of it. A lot of the schemes have a little bit of a hierarchical nature and there's some amount of like soft decoding that happens. So there are some things that probably will remain more software-ish. Interesting. Okay. So yeah, since we were wanting to talk a little bit about hardware software or system

stack design here, you know, that that's useful information or helpful information. I think the other thing that I was curious about following up on is earlier you were talking about this as like kind of like a QPU, right? So, you know, when we had things like GPUs become really prevalent as accelerators, there was a little bit of a transition for developers to A, you know, think about how to partition their problems between the CPUs and the GPUs and then B, develop the code for the accelerator piece, right? Like learning CUDA or OpenCL or something like that. Do you see a similar sort of change in how developers will have to think in terms of like, okay, here's how I partition this problem into quantum versus classical.

And then now I have to learn know learn this new framework say to express what I want to do in the quantum world in some sense I would say yes but in another sense I would say that at least for now the QPU is very constrained and so you, there may not be as much coding for the QPU as, for example, we did for CUDA or something like that. The quantum programs tend to be much smaller and sort of more specialized. And maybe there'll be a smaller number of kernels that people just sort of reuse, right? I think actually the part that maybe would require the most thought if you were a programmer trying to take advantage of the QPU is how to partition to the QPU and actually how to make use of a kernel that is really good at solving computationally hard problems of a certain type,

but actually really bad at input and output, right? And so something you can think about for a quantum machine is that it's probably not going to be a lot of bits, right? Right now, it's on the order of 100, and maybe we'll get to 1,000 or 10, ten thousand that's not a lot of bits right but the computational power is enormous right it's like two to the ten thousand right so what you have is uh you want a problem that can be described in a small number of bits that's really hard and then you can get an answer back in a small number of bits, right? You get 10,000 bits in, 10,000 bits out. Right now, more like 100 in, 100 out. And then you want that problem to be something really difficult to solve, that normally would take exponential resources to solve. Now, it's actually the case that you could

input, to be 100 bits, you could input two to the 100 values in there, but it would take you exponential time to do it. And then you've sort of lost your benefit already, right? So you want a problem that's describable in a small number of bits. So that could be like a small graph, right? But yet you're doing some graph computation that's super difficult. It could be a molecule in which you have an exponential number of interactions going on in there, and that's very difficult to model. And so there are some problems that are naturally this way. And then there are some problems that don't seem so naturally

this way, but there's some recent work by one of our collaborators, Aram Harrow at MIT, and some of our follow on work on how to use that, something called a core set for quantum algorithms. And it's essentially a sample of a large data set that then you can use to solve a representative problem and then use that to maybe inform your larger problem.

And the simplest version of that is say you were clustering a large data set, and then you have some way of sampling it, and then you cluster the samples, and that gives you a hint as to what the cluster should be for the large data set, right? They actually use core sets classically also, but it has some promise for sort of these quantum acceleration type of applications. So I imagine that that is the paradigm shift for people, you know, trying to figure out how to partition their problem, how to summarize their problem into something that, you know,

is solvable on a quantum machine in an advantageous way. But of course there's the obvious ones where, you know, is solvable on a quantum machine in an advantageous way. But of course, there's the obvious ones where, you know, you want to model some sort of quantum physics, quantum system, material problem, then, you know, perhaps that's much more obvious, right? Right. No, that's a really good summary. It sounds like what you need is like a compact problem representation, but that sort of blows up into like more exponential compute and that sort of maps really well to the quantum systems that we have today. To a large extent, it's sort of fundamental, right? You want this compact description that then becomes a lot of computation and that's how you get that exponential advantage.

So maybe we can double click on the exponential computation part itself, the kernel itself that runs on these devices. I'm sure there are a lot of challenges. Like once you know that this is the kernel that you want to accelerate, like how do you go about mapping this to the underlying hardware platform that you have

or whatever is the technology that's implementing the machine. And there are various layers in the stack. So starting from a kernel representation in some high-level language, there's a lot of layers to the stack. Like in the traditional architecture parlance, you have the compilers, you have an ISO or an architectural or an execution model for the underlying machine. And then there's a problem of mapping the problem or kernel to the underlying machine as well. So maybe you can talk about some of the challenges in this entire stack.

Where are we today? What are the gaps in this flow? And what are the interesting challenges here? Absolutely. So I'll just start with, you can think of mapping to QPU as a very specialized vertical stack of like an application specific stack, right? And

that you think of quantum applications as that sort of very specific thing. And then you map very specifically to a particular hardware platform, and probably even a specific instantiation of that platform, you have number of qubits, topology, everything. And the closest classical analog would probably be circuit synthesis for an ASIC, right? So you have particular, very specific application window, and you were synthesizing gates down to hardware and mapping it to its physical topology, right?

So I would say, as a classical person, you could sort of think of this as hardware synthesis, right? The difference here is that, and maybe it's not so different. It's very different from your compilation of programs to general purpose machines, but maybe it's not so different from certain kinds of hardware synthesis in that the programs are pretty small. We will often compile for specific input so we can get, we do very deep optimization, right?

And get an instance that's, that, you know, has all the constants propagated, all the loops unrolled. A lot of opposition that you wouldn't see in a classical machine. And since the programs are small, the machines are small, we can afford a lot more complexity. So, you know, things that we would normally do to keep our optimizations tractable and scalable, we might violate that. Right. And just, you know, unroll everything and, you know, sort of schedule out everything that we have in a very specific way. So that's where most of quantum stacks have gone, right? So this fairly optimized progress synthesis,

but still layered and abstracted. As you mentioned, we have ISAs. There's something called quantum assembly language, open quantum assembly language, OpenChasm, which most people use and provides a lot of interoperability between different software stacks and different machines out there, which is great, right? But what I will say is for the last three to five years, much of the work we've done has been to break these abstractions and essentially violate modularity and reduction of complexity and actually build software stacks that are very physics aware, that expose details of the machines that are well below

the ISA. And I'll give you a good example. The typical software flow would be you have some high-level representation, some high-level language, quantum language, and you compile it down to an ISA, which is essentially quantum gates. And then those quantum gates get compiled down to essentially the machine-level representation, which is some sort of gates that the machines represent or can implement.

So there's some translation. And then those machine gates actually get translated into control pulses. So usually they're analog microwave pulses or laser pulses, which actually implement the gates on the machine. And so there's these multiple steps. And so a few years ago, we wrote a compiler that took pieces of the program. You can think of it as a multi-bit function, right?

Treat it as an input output function of multiple bits, and then directly generated a pulse sequence that implemented that sort of macro function, right? And that ends up being, you know, two to 10x more efficient, right? You can think of it as the direct path from the start state to the end state, as opposed to a whole bunch of instructions that meander around until they get to the end. And so it's not the most scalable approach. You can only do it on a small number of bits and gates. It actually, in fact, takes exponential time to do that compilation. But there are quite a number of these physics-aware optimizations that can give us very substantial gains. And in fact, I didn't, I guess I didn't start this interview, which I often do with, you know, our project, this, our expedition called EPIC has this goal of improving the efficiency of quantum programs on machines by two to three orders of magnitude.

And the way that we're going to do that is by breaking abstraction and optimizing for the physics of machines. So that's really interesting, actually, because I think in many ways, when you think about what makes various hardwares win, there's the hardware piece, the fundamental performance of the hardware, and then the ability for people to access it through the software stack. Right. And so, you know, in some, some ways you can say the battles are won, but with better hardware, in some ways you can say the battles are won with better, better software stacks. And as of right now, you know, there's a lot of different industrial giants that have various machines and they have their own software stacks. And so now when you talk about like breaking the abstractions and making it really, really custom to the machine underneath, that makes it even sort of, you know, the fates of the two are really, really tied together. Like you kind of have to choose now which particular

machine or which particular implementation you want, and then you marry yourself to both that software stack and that machine. So I guess what I'm wondering is like, you know, in this new world, where do you think, given that everybody's kind of interested in building a, you know, quantum accelerator, where do you think the battle will be won for like, who's going to win that race, like a better machine or a better stack? Well, I mean, I think you need both, right? I think that, I mean, I think that there's much more attention being paid to better machines and better stacks. And so at some level, the bigger win is in software stacks at the moment. You know, three orders of magnitude

from the software stack is equivalent to about 20 years of hardware development, right? And so if you can implement a stack in a few years that does that, then you've cut off 20 years of time, right, in terms of making these machines happen. So I think that is our vision. Now, of course, there's some interplay between what the software stack can do and what the machines can do. And that I think is very important and exciting. Many, many of the things that we do in our software stack come from our experimentalists, right? The typical conversation would be an experimentalist would come to me and say, I can do this special thing with my machine. Can you do something with it in the software stack? And we're like, yes, we can. And so, you know, that any number of things, you know, we have this work on ternary logic, Q-trits instead of Q-bits. And, you know,

that can save you an order of magnitude in the number of devices you need in your machine, potentially. And that came from, you know, in fact, a visit I had at Yale where they were saying, we can do these three-level Q-trids. You should figure out where you can do that in software with that, right? And so that, and the same thing with this pulse optimization, right?

One of our collaborators here at UChicago uses pulse optimization to optimize sort of single qubit and two qubit gates. The question was, well, could we use that for larger functions, right? Could we just optimize the whole program with it? Turns out we can't because that's not scalable, but we can optimize chunks of it.

So there's that. The other thing I will say is that it is actually a little, maybe a little surprising, but many of the techniques that you might come up with to optimize for a specific platform will generalize to other platforms. Even though the platforms sound quite different, trapped ions and transmons or superconducting devices of different kinds, they have a lot of fundamental features that have the same architectural implications, right? They're all physical, you know, sort of 2D-ish, 1D or 2D-ish. And so they have the same sort of similar topological constraints and, you know, communication is hard. They're all controlled through some sort of analog pulse sequence of different kinds. And so there are many of the things that we come up with, even though they initially are specific to a particular technology, will translate to many other

qubit technologies and platforms. Yeah, so as you were elaborating on the importance of the software stack, so one of the thoughts that occurred to me was like in the space of accelerators, like domains specific accelerators. So one of the things that you need is, apart from the programming language, the compiler stack and all,

you need things like debugging tools or things to visualize what's going on, like either from a performance standpoint or from a correctness standpoint. So are these factors that are important in the context of a quantum system, or are we still very far away from that? This is not a concern right now. Today, they're just trying to program the machines, and people have very good visibility into the system.

How far is it away from the end user experience? And are these actually things that people care about is is terribly important actually um i haven't talked about it yet but we like in our expedition project we have a whole thrust which has to do with debugging and verification and the problem you have is that you can't simulate these machines. And if you could, then you could just simulate it cycle by cycle. And you can even look at the internal state of the machine and know what's happening and know if you read something wrong in your quantum program. Or if the machine is disagreeing with what you should be doing, right? The physical machine isn't doing what it should be doing.

In reality, what's going to happen is you're going to scale your programs up. You can't simulate them. You're going to run it on the machine and you basically won't be able to test it very well, right? So it's very hard to look at the internal state of the system. You can't step through and you can't look at anything. When you measure the system, your program's over, right? So you can run the whole thing to the end, measure and get a few bits out. You can run it somewhere to the middle, measure and get a few bits out. But every time you just have to start over, right? There's no stepping through. And, you know, there are a lot of times where you might want to know, oh, I wish I knew what the quantum state was here in the middle. And that is an exponentially large quantity. And

it actually would take an exponential number of measurements to figure out what the state was right there. So it's actually a horrible problem. And we actually have a pretty large effort in trying to formally verify quantum programs, quantum compilers. Because, you know, I think of it this way, we actually have a fair amount of formal sort of formal technology, formal methods for verification. But we're usually a little lazy about using it, because it's sort of hard. And we could just test our programs, right? Well, in the quantum world, we can't. And so there is quite a premium on being able to prove that what, for example, your software is correct.

So that when the day comes that we have a big machine, we're going to run our software on it. Well, we know we've pushed the limits of technology, the machine sort of buggy. Right. And we know that we haven't really been able to test our software and run this thing. Probably not going to end that well. Right. And if you, if the result isn't right, we won't really know whose fault it was necessarily. And so there's a lot of interesting things, a lot of interesting

problems, hard problems there. I will say that thus far, people have just sort of been careful, you know, just try to, you know, incrementally test a thing on small problems, large problems and just do the best they can. But I think we definitely are gonna get in trouble eventually if we don't develop a methodology to deal with these things. There's some nice work out of Princeton and then NC State had some ball on work

on like quantum assertions, different ways of looking for errors in your programs. And there are just, you know, there are just a lot of interesting problems here. There's a fundamental issue here, which is that if I try to verify a property of my quantum program in tractable time, say polynomial time, and that property is too close or say reducible to the answer, right, the result of that program, right, you've just proven that that program has no exponential advantage, actually, right? If you have a program that has an exponential advantage, then you know it's going to be hard, right, to verify it. And there's maybe an interesting fundamental question is how many properties can you test for that are far enough away from the result that are useful in terms of sort of debugging your program or giving you some assurance that it's correct?

We don't know that. So there's a well-motivated, very long line of research coming in that area. That's super, that's super interesting, Fred. So I think if I may try and repeat back, you know, a high level train of thought that I got out of that. So with classical computing, we work very, very, very hard to make sure that the machines themselves are error free. And so if there's a problem, it's usually the software and the software is easily debuggable. So we can get lazy about writing our software. And then we

kind of like rerun it or check it later. Cause we can stick all this stuff, you know, print statements or whatever. And, but it sounds like what you're saying and correct me if I'm wrong, cause I could totally be wrong, but that like, because the machines themselves are so error prone, really the thing that you try and verify is the correctness of the program. So that if something goes wrong, you want to make sure the program is right. And so that you can deduce that it was the hardware that was wrong. Is that, is that kind of how it is? That would be one way to look at it, because I think that it is never going to be the case that the hardware makes no errors. And well, I mean, maybe maybe you could think of it, if the hardware is error corrected, maybe it could be

error-free. But at some level, the error correction software, it's sort of software, right? And so you at least need to verify that so that when you run it on top of the machine, you know, because the underlying physical hardware will always be error-prone, right? Maybe errors that you understand, maybe not completely. Yeah, that's so interesting. That's like a total flip-flop, right? To want to formally verify your software because you just can't rely on the hardware. That's fascinating.

What is one big open question that you'd like to see solved in quantum computer architecture or quantum systems? Yeah, I mean, actually, the thing I would like to see solved is that we have techniques right now for error mitigation, which is essentially, well, okay, so let me put it this way. The way that we've been making machines better for the last five years is essentially by being more careful, like making the devices more carefully, calibrating them more carefully.

And so, you know, we're sort of going from like one nine of reliability to two nines to maybe three nines by being super careful. There's no way we're going to get to five nines that way, right? And so these error mitigation techniques are basically ways of taking ensembles of devices and making, essentially simulating a better physical device right and that's going to give us hope maybe like two more nines or something like that but we actually don't know how to marry error mitigation with error correction right and so that is actually probably like i think of as at a system level or architecture level something that needs to be solved it's a little bit hard to phrase a sort of grand challenge problem like that that's completely accessible to architects actually right um you know i think of that in the context of systems and quantum computing

the grand challenge for algorithms people has come up with better algorithms right but the grand challenge resistance people is probably something like that right you know maybe a more that if i had to pick one that would be it but but it may be a more architecture appropriate one is that for example recently we found some really nice matches from between error correction codes that people want to run and uh like 3d or two and a half d architectures like sort of topologically if we found a technology build it you could build two and a half d tech sort of system with it and then it maps really well to the dominant error correction code that people want to use. And so that is sort of like a good architecture problem, right? Looking at different organizations of devices and looking at how well that matches something you really want to

run. And there are probably more such mappings or such matches of things out there. So I think there was one other kind of large high-level question that I was hoping to ask you today before maybe we transition into talking about your career, which is, you know, when I was a grad student, like AI was a thing where people were like, yeah, you know, people have been promising cool stuff on that forever. It's still a long way away. It's been around for a long time. It's like the, I think it was pretty much one of the AI winters when I was a grad student.

And then something just happened and it took off, right? And so oftentimes, you know, given that Microsoft has a presence in the quantum world and I was quantum adjacent um for a while when i was here people would ask me and i would say like it seems to me like it's kind of similar to this right like it's you know there's a there was a step function and then something's going to happen and boom and it sounds like what you're saying is like but the the fact that we now actually have machines where you can like real machines it's we're maybe approaching the beginning of you know like a super hockey stick would you say that's the case like would that that we're at the beginning of a super hockey stick for for quantum and if that's the case you know do you advise our you

know our listeners who are still in school to to go into this space and if so you know what should what should they be thinking about? I think there is an inflection point here with these new machines. And I think it's certainly scientifically very interesting. I would say that maybe the super hotkey stick is a little bit further away that, you know, probably the super hotkey stick is going to come when we get default tolerant machines, you know, and maybe that's five years away, right? We're already at the point where we have machines that are sort of historically different from classical machines, but it, but I would say we're probably five years away from, you know, sort of useful applications and getting to the scale that maybe we have fault tolerance and then continually large machines.

Some people might say that's 10 years away. As an optimist, I would say it could be five. But I think we're still a little bit at the deep tech stage here for quantum, right? Like it's still a little bit of long-term investment. You see the federal government going into this in sort of the 10 to 20 year time scale with the National Quantum Initiative. And you see companies going into it. Hopefully they'll have the stamina to get, you know, five years more so that we get to something

where they can start seeing some big benefits. But I think one has to be prepared for a five to 10-year campaign before you see that really big acceleration. So before it was like always 10 years away and it would stay 10 years away forever. But in this case, you feel like it is you know somewhere between five and ten years away so that that's cool i i think the other piece though about like students um i don't know if you were going to reiterate on that subna but like students who are interested in the field i think there is um you know there is a lot of need right now for a sort of more system level and software level view

of quantum systems, of quantum machines, right? I think that we are at a point where, you know, the hardware platforms have reached a point where you need the system on top of it. And everyone's realizing both in industry and academia that we don't have the people for that. So I think at the scale of maybe a small industry and at the scale of academia, I think there's a great need.

And I think it would be maybe five to 10 years from now before it's like the scale of machine learning or something where everyone should be doing it. But there's certainly already a big shortage, maybe on the order of thousands of researchers, maybe thousands or tens of thousands of engineers, that kind of thing. We're not at 100,000 or anything like that yet, but it's a small industry. But certainly at the research level, there's a huge shortage. There are lots of universities trying to ramp up on this.

And I think the place that they're shortest on is this sort of architecture systems and software regime. I think if you're at the level of PhD student, that probably definitely is promising, right? Because with respect at the level of PhD student, that probably definitely is promising, right? Because with respect to the number of PhD students, it's not a small number that are needed. I see. Yeah, just expanding a little more on that. So someone with, let's say, a good systems background who is looking into this particular space, this obviously spans multiple layers of the stack. And now you've got like physics and some amount of mathematics also coming in. So what sort of skill sets or broad-based fundamentals

would you advise, you know, a systems person or someone with an architecture background, like what are the essential things that they should sort of study and skill sets that they should develop in terms of being able to understand these systems with reasonable enough depth that you can then work on top of it as a systems person. Right. I mean, there's a certain level of abstraction that you can work with that probably just requires a little bit of linear algebra and classical systems knowledge. You know, the kind of work sort of at the very cutting edge where we're trying to optimize for the physics of machines, then, you know, it would be, it is helpful to have some understanding of, of device physics and quantum device physics, actually. And, you know,

that actually is fairly specialized. I mean, there, there are, even, even if I take a student who has a physics degree, for example, they just, the most important thing they learn probably are things they learn are for like a specific technology, how is it controlled, right? And what are its properties? And there are just a few classes and papers that sort of cover that kind of thing, right? I think there's a certain comfort level with some of those things that help that is helpful if you have some physics background and one can pick it up i think but you know i think i guess there's a certain level of work you see our classical architecture groups getting into this where they're sort of working at the isa level and working at maybe the device level where they can do look at errors and variation.

And then there's sort of like one more level beyond that, which maybe is a narrower set of people anyway, where you're more optimized for the physics of the machines. I would say that there is an effort to make this more accessible to people. In fact, my student Yangchan Ding, who is going to Yale, we had a book come out last year that he was the primary author of that is really a computer systems view of quantum computing and trying to give a broad view of like, what do the problems look like in quantum computation?

And how, what classical techniques do you bring to bear to solve those problems? So I think there is sort of an entry point. In fact, that's going to be an edX class workshop at Micro-Norwiska this year, which is something they call i2 CanQuantum. And it basically targets classical architects who want to get into this space and pairs them up with mentors in the field and tries to, and actually is a development process for their ideas. So I think it's possible.

It is, when I first got into this 20 years ago, I actually personally worked at a very high level of abstraction. You know, it's just an ISA and it's just a compilation problem. And it's a little bit less like that now. It takes a little bit more work maybe to get at least at the cutting edge of what needs to be done. But there, you know, there are systems problems that maybe are even fairly abstract. Yeah. So this, this was totally leading me to ask, like, how did,

what was your path into this field? You know, you started in sort of computer architecture and then, you know, have, you know, over the last couple of decades become one of the leading lights in quantum in our field. So how did that transition happen for you? Yeah, that's an interesting question. You know, I'm asked this question and maybe more generally how I chose the different topics in my career quite often. And I guess my first answer is, you know, you have to be willing to sort of jump and do something interesting. But the topics that I've worked on in my career are largely serendipitous. You know, so the three major things I've worked on in my career were sort of near

memory computing really early on, hardware security pretty early on, and then quantum 20 some years ago. And looking back, boy, those three were pretty good bets. But, you know, it wasn't like I necessarily knew that when I did it. You know, I mostly did it just because I thought they were interesting problems. And so the way I got into quantum actually is really just because I went to school as an undergrad at MIT with Ike Chuan, who built the first quantum machine, really. He built a bulk spin NMR machine. He was at IBM. He's a faculty member at MIT these days.

And Ike just came to me back in 2000 or so and sort of said, hey, you know, it's time that we started looking at architecture for these systems. You know, they're getting big enough. And we built a DARPA project with me and Ike and actually John Kubitalitz at Berkeley, who we also went to school with. And, you know, I just said, oh, I'm going to find two good architects and start working on

this. And I think that, you know, the reason how I got into it was like, oh, I was willing to say yes. Right. And I actually had the good fortune of having, you know, one of the founders of the field from the physics side and who actually wrote this book that we call Mike and Ike which is the bible of quantum computing giant book and he just sat down for a few hours and just like wrote in my notebook and taught me enough about quantum computation to get started right one? One-on-one. And so, I would credit Ike with getting me into this, but at the time, why did I get into it? It was, back then, I think the field

of computer architecture was still pretty constrained by commodity forces, right? The most, the most, the easiest thing to do was to work on a, I don't know, a branch predictor or cache algorithm

for a risk processor or an x86 or something. And that was a little constraining, right? And so, you know, here was a new area of computer architecture where you could basically do anything you wanted, right?

And to me, that was just in itself worth doing. And in many ways, for a couple of decades off and on, it was a little bit of a hobby. And it's an interesting field because it has some national security implications. So every now and then there'd be a lot of funding and it'd become like a sort of focus area. And then, you know, then it would go off, sometimes become classified. And, you know, so there were different things that happened along the way. And then, you know, it got to the point where industry picked it up and it became, you know, national initiative, at least a public national initiative. So that's that's I guess that how it, how it came about.

I don't know. Life is serendipitous and work with smart people and get good students. That's how it works. Right. Speaking of smart students and good people, any words of advice or wisdom to our listeners based on your experience or in general? I definitely see the, just in terms of smart people, you know, I've been fortunate that I guess lots of smart people have been willing to work with me, right? Like I, you know, really it is these interdisciplinary areas.

It is, you know, it's so much, it is a lot of work, right, to learn about all these different sort of intersecting fields. And, and to some level, it's not possible to be an expert in all of those fields simultaneously, right. And a lot of it boils down to, you know, just talking to smart people in each field, right, and spending a lot of it boils down to just talking to smart people in each field and spending a lot of time learning their language, working with them and building relationships that bridge those gaps. So that's one thing. And I've definitely spent a lot of time doing that in my career. And, you know, and sort of bridging the timescales and the cultures of different fields. Right. You know, you know, a physicist might tell you they're going to do something or write a paper about it. the time scales and the cultures of different fields, right?

You know, a physicist might tell you they're going to do something or write a paper about it, and it's five years in the future, right? And I would go, what? I was thinking five months. You know? And so that's something you have to work with, right? With students, I mean, I tend to – I give my students a lot of freedom, and I think that's really key. You know, I don't know. I've been lucky to have really, really good students.

Part of it, I think, is maybe working on unusual, unorthodox topics. I think that is an attractor. I don't know. Part of it is just treating them well, you know, and letting and trusting them, really. I don't know. I don't know why I've been so lucky with that. That's so great to hear you speak so humbly about your your great career fred it's been a total delight talking to you today i've learned a lot i always have fun talking with you and um we're really appreciative that you're able to join us today yeah this was fun thanks for asking me on your show yeah thank you fred for the whirlwind tour of quantum computing and the system stack for quantum computers.

I think we could have spent a lot of time delving further into just each one of those threads and talking with you for hours on end. But thank you so much for educating us and our audience on this really fascinating space. And to our listeners, thank you for being with us on the Computer Architecture Podcast. Till next time, it's goodbye from us.