Kevin Rowney: Welcome back. Today we have Dr. Cassandra Granade, who's the author of Quantum computing with Python and Q Sharp from Manning publications. Such a great shop. I love their books. She's also the owner and principle of Dual Space Solutions, LLC, and is a prime contributor to the fasting project of the QIR Alliance, and we'll be talking about that at some length today.
Sebastian: Kevin Quantum intermediate representation is what that acronym expands out to. This is a really interesting project. Open Source, open standard project. That the QIR alliance is driving that. Cassandra is one of the prime movers behind. And the work that they're doing is to create this intermediate representation that's meant to promote better portability of code in the quantum space.
And intermediate representation is a way to. Provide a middle ground, if you will, between the lower level of the stack, the hardware specific functionality, and the higher end of the stack. The higher level language is the general purpose language is things like python, rust, and the like.
So it's a really interesting topic. It's become one of the hot topics within the quantum information science community. And I'm really interested to hear more from Cassandra.
Sebastian: Welcome back. We are joined today by a special guest, Cassandra Grenade who an independent consultant in the quantum space with a quite an interesting professional path and academic career in their background. And Cassandra, would you mind thank you for joining us. Would you mind introducing yourself and give us a little bit idea of how you got to where you are today?
Cassandra: Absolutely, and thanks for having me wonderful to be here today. as Far as how I got to be where I am today, that's... That's always a fascinating question.
Sebastian: Isn't it?
Cassandra: I, and in part because I think I got to where I am, that followed the particular path I did by virtue of being very bad at making decisions about what I want to be when I grow up.
Kevin: Oh my
Cassandra: I go back to like undergrad and I did the very unusual thing of a triple major because I couldn't make up my mind whether to do math, physics or computer science. And seven years later, I never did make up my mind. And
Sebastian: to perfectly describe the intersection that you need for quantum information science.
Cassandra: Exactly. And it's where can I apply all three of these? This quantum computing thing looks pretty good.
Sebastian: So convenient.
Cassandra: Yeah, but so from there started with grad school at Perimeter Institute was one of the inaugural year of Perimeter Scholars, um, and that was really neat, had a lot of different perspectives that I wouldn't have ordinarily gotten, I think, coming through a Sort of quantum computing focused or CS focused or even pure physics focused.
It really was a lot more interdisciplinary
Kevin: Yeah. It sounds like a cool scene. Yeah, no
Cassandra: Yeah, absolutely Went from there to do my PhD at uwaterloo before doing a postdoc at University of Sydney And from there decided to come back to the US To join Microsoft, was there for about five, five and a half years and recently made the move to be independent and launch my own consultancy.
And that's been a lot of fun.
Sebastian: that's dual space, right? Is your consulting? Dual space solutions. Yeah. And is there anything in particular that you're trying to focus on with dual space or is it fairly broad or how would you characterize your offering?
Cassandra: My joke around that is always, my niche has long been not having a niche -- above about, being very bad at deciding what I wanted. That's all the cheeky and humorous way to put it, but the more serious answer is My strength across my career has always been taking an interdisciplinary approach.
Being able to find, what part of a problem is not being seen, what's missing, and try and go explore that part. And that's what I try to bring with dual space solutions as well is to not say define myself into a particular niche, but rather to be able to say if you have some broad strategic question, what are you missing?
If you're trying to look at some program as a whole, where are the parts where, maybe you're not taking into account culture and workplace or community, maybe you're not taking into account Some classical computer science, but that, there's a communications breakdown between the sort of CS or physics mindsets around things.
Kevin: Sounds really cool. I've done some of the solo consulting stuff in the past and it can be, a complicated thing to run. Respect that's impressive. , I was just wondering, Cassandra, could you give us a little bit more detail about the nature of some of your engagements that you're doing? It sounds really interesting.
Cassandra: it. Yeah, so it is fairly new so I've been doing this a few months as an independent consultant now. And I think where I'm most excited to look is... Collaborating, as mentioned around finding places where existing expertise at a company may not cover.
Everything and where I can try and provide some of that context and for that I do bring my PhD and postdoc were around software for statistical characterization. So QCVV, and that brought a lot of software focus to doing physics experiments. A lot of my work at Microsoft was, connecting research ideas to software implementations.
And that's the same kind of expertise that I bring now to solo consultancy work is trying to connect some of those two across. So I like it. It kind of discussion I really love having is, hey, here's an interesting research idea. How do we take and put this into software or here's some software?
What are we missing in terms of the research context in which software will be used? Or, here's some classical computer science idea. What's wrong with it about that, as we generalize that to quantum or alternatively and arguably more importantly, what's right? What do we not have to throw out about classical software history as we're coming to a quantum context? So I mean from all those different perspectives, what I'm really excited about working with, folks across the industry is finding places where those connections. aren't happening, or maybe they are happening, the outside perspective on the collaboration is still really helpful.
Yeah.
Sebastian: I joked about, that's the perfect sort of set of disciplines to intersect to create quantum computing but that is really true in a way. That interdisciplinary perspective is particularly valuable at this stage of an emerging technology when in large part we don't know what we don't know and it does, it very rarely is the best strategy to assume, based on priors, I know how to approach this problem and I'm just going to You know, weight in and treat it like, like previous contexts that I'm familiar with.
And often you need that kind of outside perspective, bringing in some unexpected viewpoint or some tool in the, that you are lacking in your toolkit. So that, that sounds like a really valuable approach.
Kevin: No doubt.
Cassandra: absolutely. And I think across the field, we are seeing a lot of places where that is necessary. There's also the opposite of, sometimes things are a little bit different in quantum and we need to know when to throw out bits of history, when to keep them. anD I mean that I think the two most dangerous things you can modes you can get into is Oh, quantum is just, like classical computer science, so we know exactly how to do that.
Or, quantum is nothing like classical computer science, so let's throw out everything we've ever learned. Eh, I know it's kind of cliche and everything to talk about how weird quantum mechanics is. I think it really isn't as weird as all that. There is a lot we can learn. But occasionally there are things that we really do need to rethink something classically. And the challenge is being able to really tell the two apart.
How do we be, how do we act judiciously and, really pick out the parts of classical computing history that are essential to keep that are really going to save us a lot of reinventing the wheel. And I'll say, I think that somewhere that like physics as a sort of curriculum, less than an industry, less than a discipline, if you talk about physics majors, that's somewhere where I think, A lot of students are really let down and it's causes a lot of reinventing the wheel.
Kevin: Yeah.
Cassandra: Throw out the wheel if it's not working I'm not trying to say we should be constrained by history, but if you don't know what you're throwing out and you're not doing it on purpose, then it's really easy to reinvent the mistakes instead of adapting to, your what's unique about your situation,
Kevin: So this is an interesting thread of conversation. I wonder, can we drill down? What major elements, our audience are many of them, really into tech or, that fast moving advances within the sciences. What elements of classical computing trade craft do you think are really important to preserve within quantum computing and what areas and traditions are just get tossed out entirely?
Help us see the landscape as you see it.
Cassandra: A lot of my PhD and kind of postdoc, if I go into a lab The vast majority of problems that I see people struggling with in a lab are software, right? Because, now, there's a giant caveat there. That's, some ten odd years ago and I think things have improved immensely since then, but it really used to be okay, if it's not a software problem, then the people in that lab are well equipped to solve it.
And so you see everything being a software problem, not because that's somehow more foundational or it's more fundamental, but because people have solved everything else and that's what's left. And it's a lot of... I think of the work I've done and language design and collaboration things like that, or, how much of just writing classical software comes down to string handling or writing, uh, boring sort of loading config files, saving config files, things like that comes down to managing your source code, with,
Things like Git, tracking issues, and that's a lot of the workflow that again, I think isn't really part of the physics
Sebastian: Right.
Cassandra: So it's always a stumbling block again when you get to, oh, hey, my job is now also software because I'm managing a lab or I'm trying to and so I think that is, and I, there again my comments are really about physics as a curriculum rather than physics as a practice, and where I think students encounter stumbling blocks and work through it, I don't know, you stare at any piece of software long enough and it's a string handling problem, whether that's star IDM on some GPIB connection or whether it's, try and export.
Plot and writing out graphics primitives, like you're still at some point doing the same sort of string handling that's been done since, well, computers.
Kevin: No doubt. Yeah.
Sebastian: And is that level of sort of abstraction from the perspective of CS that the discipline of CS, is that sort of where you came from when you started working on the subject I'd really like to dig into the most in a way is, which is QIR, the Quantum Intermediate Representation
Cassandra: Yeah,
Sebastian: Yeah.
Cassandra: so I really see QIR as a very radical attempt to not reinvent any more wheels. So if you talk about a what a quantum program is we've known since about 2005 as an industry since before, really, we thought of it as an industry, right? We've known since about 2005 that fault tolerant quantum computation involves a lot of conditioning quantum operations on the results of measurements.
And this comes about due to the demands of fault tolerance threshold theorem, that you're doing error correction, you're doing a lot of decoding, things like that. And there are certainly tricks and techniques, and we've learned a lot since 2005. I don't think fault tolerance in 2023 looks the same way it did in 2005.
But the piece that I think is really important that we carry with us even now is that quantum programs aren't circuits. Circuits are part of quantum programs. That you have also all of this rich classical logic going about. And decoders are... In general, fairly complicated compared to, the kinds of classical logic that we can write out with double lines and a circuit notation.
There's some pretty simple decoders, but even the simplest are still going to look complicated compared to that, the control flow that looks nice in a circuit diagram. And that, that really does say, all right, we need a way to write down what a. Quantum program is we know it has these classical elements.
And as soon as you get to that just throw out the quantum part It's hard to write down those classical processing elements People have tried for decades and decades to have you know a way of writing down A classical algorithm in some portable way,
The promise of write once run anywhere with Java.
The idea and there were
Sebastian: A triumph of marketing, you have to
Cassandra: I yeah, no argument, and that's even in a case where we're pretty spoiled by the fact that most classical processors look the same at the level of writing out, a block diagram and pseudocode. The details are incredibly important, but I can still treat mathematically, an ARM core and an x86 core as being roughly the same in terms of there's an instruction counter and a program counter and they proceed through, and it looks vaguely like a random access machine in both cases.
And at the level of, writing down what a classical program is, Those details matter a lot, but it means I can use the same kind of abstractment in both cases, and even there it's been a decades long problem
That out. aNd that's before I even allocate my first qubit, I have to have something that is at least as hard as this problem that's taken us, a few decades to have really good approaches on the classical side.
And so the kind of radical not reinventing a wheel is... Let's not do that. Let's just actually use the tools that the classical CS community has developed over those decades. There's no perfect solution, but that work pretty well at giving you portable representations of classical programs across different architectures and across different CPUs.
And, it's been neat looking at how much the LLVM project has done classically. And that it first off decouples the idea of what a language is from how do I reduce code down to a given processor? But making that step has also enabled some pretty surprising things like that You can target GPUs or FPGAs sometimes or even target things that just Would have been really weird to imagine at the start of LLVM like targeting web assembly I mean for a little while you could Look to things like in script and for compiling C to JavaScript, which feels exactly backwards, but was really useful in taking some legacy code and making it available for folks to use in the web browser driven world.
And that's the kind of really surprising reinvention that I think was enabled by having handoff between frontends and backends. So QIR really does build on that by saying. Look, we're going to, at some point, have to write down a classical program, whether it's a decoder, whether it's, some repeat until success algorithm.
So let's start with a baseline of something that can represent classical programs, and then build on top of that the things we really need for quantum.
Kevin: So this is such an interesting thread and, we're in some sense just hobbyists and not experts like you, but we try to get close as we can given our abilities to what's going on in these underlying architectures, but it will be surprising to hear from you that, that the diversity in quantum computing architectures can be sufficiently abstracted to fit into a broad enough framework.
I agree with you that different. CPU types in classical computing there's one abstraction that can cover, virtually all of them. Is it really the case then that the diverse array of quantum computing architectures can also be successfully abstracted?
Cassandra: There, we're saved again by, the fault tolerant threshold theorem, right?
Kevin: Yeah.
Cassandra: The whole idea of fault tolerance is, in some sense, is to abstract away what errors look like in your device. Thanks.
Kevin: Ah,
Cassandra: But that also means you're abstracting away the details of that device in particular and reducing it down to Instructions that are, part of your error correcting code and so forth.
That's part of why, things like the Clifford group has the importance that they do. is Because the role that they play in fault tolerant arguments and things like that.
Sebastian: So then are you saying that sorry, Kevin does that, am I right in? I'm thinking then that you're leaving fault tolerance, the task of fault tolerance to the QPU, and you're assuming that input is is these idealized circuits that will then be implemented at the hardware level in a way that that, meets the fault tolerance threshold in whatever way is appropriate on that piece of hardware.
Is that right?
Cassandra: I'm not saying that I'm in the, in particular, I don't want to make a statement at all as to what happens inside, a service provider in terms of how they take that. I know there have been talks, for instance, from like IBM, where they've shown a little bit behind where, they accept input and what they do with it.
And that does look, like you're saying, we've heard things like a successive lowering amongst different IRs, but, it's I'm certainly trying to stay gnostic on that and think from the standpoint of, what is a good point of. Where is it that we
Cassandra: Not specialize our languages, our compilers, our compilation passes and our optimizers and things like that to one service provider?
While still keeping the generality we need to really match, the, what we've learned from sort of 2005 era thinking together with what we've learned about the importance of near time again, to borrow IBM's terminology but to, the importance of near time processing adjacent to your quantum program.
Sebastian: Which goes back to your point about fall tolerance error correction. They're gonna need a lot of very tightly coupled quantum resources and classical resources to encode and decode and make decisions ba conditioned on the output of a prior circuit.
Cassandra: Yeah, and to take a little bit of a brief tangent by way of answering that, I think, where, we've seen a lot of really exciting things come out of near term quantum devices is when they teach us how to build better quantum devices. Now, there are many other exciting things about, I'm picking out the thing that excites me the most out of which is and so there, if you look at a lot of kind of near term algorithms, they have this flavor of do a thing classically, do a thing quantumly, do a thing classically, do a thing quantumly and, that there's this alternation between.
And the tighter you can make that alternation, the less times you're, making round trips back and forth with a service provider, and the better everybody's life gets. That's another mode of integrating classical and quantum computation that I think wasn't really obvious in 2005, early fault tolerance era.
But now is a feature that we probably will expect to see carrying forward to larger and larger devices, in addition to that tighter real time mode that you mentioned just
Sebastian: right
Kevin: Right. And just for the benefit of our audience, I could think of at least two examples where that classical quantum interchange is very common. One's, of course, the quantum variational eigen solvers, right? And the other is all of these interesting algorithms where classical compute capacities are being used to essentially tune a An error correction algorithm for quantum computation.
Are there other concrete examples of this sort of, for the benefit of our audience on this, classical quantum interchange, which have a broad application?
Cassandra: I do think, you called out variational algorithms like VQE. I think that is the quintessential place where we see that that alternation where there's classical. prOcessing that happens on a timescale that's long compared to qubit lifetimes. And then there's things that look more non adaptive within qubit lifetimes.
And variational there is the clue, right? It's the word that says, I'm minimizing a function. aNd everything about black box optimization and classical computer science. really need to know what thing I'm minimizing to have that sort of alternating structure of I make calls into this thing, I look at the value and use that to decide where I call it next.
Kevin: Yes. Yeah. Yeah. Makes sense. I gather there's probably also some, I think some quantum machine learning algorithms as well, that do a lot of that same kind of back and forth classical quantum alternation.
Cassandra: yeah, so certainly not trying to say it's exclusive, rather the opposite that I think, what we see. In what I think we really learn out of variational algorithms, um, and again, there's many exciting things, but the thing that, excites me when we're talking about stuff like QIR is like okay, what do we need to take with us as we build larger devices, as we build toward fault tolerance and, the insight that yes, we have classical computation happening both at time scales that are long compared to qubit lifetimes and that are short compared to qubit lifetimes.
And we need some uniform way of representing both of those.
That's... That's the insight that I think is really important there and really interesting when we're looking at both sort of 2005 style arguments, what we've learned about variational algorithms since 2016, and where we would like to be as we build out fault tolerant devices as an industry.
Kevin: And I have to agree with you, it really is a fascinating question and really at the outer limit of skill sets of two separate professionals who are well known for their IQ and their energy. Amongst physicists, quantum computing is a no mess around subject, amongst computer science people, compiler optimization is also the deep end of the pool.
You're doing like two, two hard things. And it at the same time with this rather ambitious project.
Cassandra: Yeah it's been a challenge in classical computer science to say, let me write down... A description of a classical program that doesn't depend deeply on the details of any particular processor so that I can lower down to a processor, um, as a next step, that if I look before LLVM and things like LLVM, I think now LLVM has won out in some pretty significant Parts of that space, if I look before that, or at least before it was clear that LLVM was a good sort of industry consensus, I, if I have some processor that I want to run things on, I have to pick a language that is supported on that processor, right?
Rather than saying, Hey, I want to write a program and I want to use a processor. And the thing is, that's how the world looks. Now, today, in classical computer science, if I look at embedded devices,
So my partner and I as a hobby, we, like instrumenting our house with like different CO2 sensors or putting telemetry on our boat and things like that.
And a lot of that is writing things, for different ESP32 microcontrollers and stuff like that. And if you look at microcontroller world today. There isn't such a thing as the C language. There's the C language as this microprocessor, or sorry, microcontroller company implemented, and the C language as this company implemented.
And the idea of C being a standard is unheard of. They're all like, weird quirks about whitespace formatting that depend on and it's okay, I get the details between these different microcontrollers matter, but I didn't think whitespace was one of them, right? But it just comes along for the ride.
Sebastian: string manipulation again.
Kevin: Yeah.
Cassandra: So if you're writing a compiler for, your bespoke microcontroller and you're starting these days, it probably is going to look more like taking something like LLVM and writing a lowering step from LLVM IR to the things that make your architecture unique than starting with let me first write down what a string is, and I think that's where we really can learn a lot from classical computer science history there.
And why, I think QIR is as exciting. yEah, there's a lot of differences between different quantum architectures, but there's also a lot that is in common.
And trying to start by abstracting over the commonality that we can,
Sebastian: Yeah. If I could take another another tag, like when you, so OpenQASM is the existing, I would say probably most used, most leveraged OpenStandard for representing primitives on a QPU, right? The circuits, the gates when you compare QIR to OpenQASM, is the, does the difference boil down to exactly what you said before that, that fault tolerant quantum computing, In 2005 was a, there's a different understanding of that topic than there is now, and QIR incorporates our new understanding of that, that topic compared to OpenChasm, which is a 2005 version of what that, that looked like.
Cassandra: So I'm going to give two very different answers to that because it depends highly on whether you're talking about OpenQuasm 2. 0 or OpenQuasm 3. 0. I really think those are very different topics as far as that's concerned. anD we'll give you very different answers to that. And the 2. 0 case, that's some OpenQuasm 2.
0 is a great language for writing down circuits with little to no classical control. Things that where the most complicated classical control you get look something like teleportation or things like that. But where I can't really do anything like a while loop, right? That you might expect out of, say, a repeat until success algorithm. There have certainly been extensions to OpenQuasm 2 that try to allow that. There had, you can take and loop unroll. But then you're paying a lot of overhead and propagating through those controls. And you have to have a very small finite number of iterations that you can consider. And it composes really badly to do everything loop unrolled.
So OpenQuasm 2, it's a great language for writing down quantum circuits that are either entirely non adaptive or have very little classical adaptivity. With things like OpenQuasm 3. 0, we're starting to see, again I think that industry can sense this, that we need a lot better representation for classical control reflected there as well.
But, where I see... Where I'm both excited about OpenQuasm 3 and where, I do disagree with it some, I think OpenQuasm 3 is a great high level quantum language. I don't think it's really what we want out of an intermediate representation. And the reason why is there's a lot of great high level things like, looking at taking powers of a gate or looking at adjoints of a gate or controlled operations and things like that are exactly the kinds of conveniences you want in a higher level language to be able to efficiently write out quantum programs, but are exactly the kind of overhead that you don't want to think about if you're taking a already compiled quantum program and lowering it down to the specifics of a particular piece of hardware.
And that's fine. Like that's in fact, the whole sort of game that we're trying to play here as an industry is how do we take and abstract out the things we can abstract out and focus, tools on the things that they're really good at, so to my mind I really seeing OpenQuest in 3 as a high level language,
I think, it is, it's great to see that there are more and more high level languages, Um, that do in fact have the capability for expressing some fairly sophisticated classical control algorithms.
We see OpenQuasm3, we see Qsharp, we see CudaQuantum. There is a talk at Quantum Week about RiverLane, sorry, Xanadu's work with RiverLane along those lines. And it was great to see that talk. And then that, to my mind, increases the need to have some common sort of intermediate representation.
If I'm, a researcher working on, some neat new circuit optimization technique, the last thing in the world I want to do is have to think about all of the nice high level features that OpenQuasm 3 provides its users to be able to write out programs by hand. I just want to know...
Excuse me. This is the list of actual operations
And that, that looks a lot more like an IR and I think that's part of why, you start to see stack and OpenQuasm 3, I think, could be a part of that stack. I, but I think, if we're looking at intermediate representations that can handle the requirements, we know both from current near term devices.
And from the sort of 2005 era fault tolerance arguments that have continued through to today, QIR is what we've got. There aren't really alternatives that deal with that at the moment. iF there are alternatives that are developed, that's awesome. I don't think it's one of those where, um, the first thing that we think of is always, the best or what'll carry on for decades.
But right now, if you're looking to develop tools that can act on quantum programs in general, then I think QI HR is looking like a really good choice for that. And I think that really opens the design space for languages. I hope we'll see more. I mentioned four different ones there. I hope we'll see more, use the fact that, QIR does offer that nice point of handoff
And start to really see more exploration of the design space for quantum programs that can include classical adaptivity.
Kevin: This is just great detail. Thank you. And help bottom line this for our audience. In terms of the ultimate effect on the overall ecosystem of coders and, theoreticians and so forth that use these systems, where do you see the primary expression of... of traction of benefit of the QR system.
Is it developer productivity? Is it compiler optimizations? Is it, better interchange and portability? I'm not sure what's the primary effect.
Cassandra: It's hard to talk about all, any of those without acknowledging or, giving voice to, I think the biggest one of it just changes what we mean by what a quantum computer is. To look a lot more like the sort of scalable devices we hope to build instead of the devices, the really exciting devices we've been able to build for the past almost 10 years that have taught us an immense amount that we've been able to do a lot of really cool stuff with, but maybe don't have all of the Architectural details that we expect things to eventually look like, um, so I mean it's productivity and portability and interoperability are all things that I think are really great to have on the forefront of our minds, but there's the even more exciting thing to me of.
We're just changing what a quantum device looks like as an industry, as our consensus sort of shifts and our capabilities and is an industry evolve to look more like what we need out of scalable, practical quantum devices.
Kevin: And so more specifically, that means you, you believe, I'm guessing deeper and richer expression of error control and error correction and the, these hybrid classical and quantum computing capacities more deeply integrated. Is that
Cassandra: yeah, so we, I think there's. At this point, a lot of good understanding at, a mathematical level, at a practical level of having tried it and seen where it got us. Quantum programs do not look like circuits. Circuits look like subroutines in
Cassandra: That doesn't mean circuits are bad, circuits are useless.
Circuits are great, but they're subroutines. They're not programs.
Sebastian: Yeah.
Cassandra: And having something that includes everything we've learned about pure circuits and can put that into the context of a full quantum program. That's the kind of infrastructure and that's the kind of architecture we need to keep going.
Sebastian: aNd help me with something else, because I, this is probably my mistaken framing, but OpenPulse was released with OpenChasm3, and it feels like OpenPulse is a lower level construct than what you're talking about. When you said OpenChasm3 is a high level language, I get it on the circuit and gate description level, but on the pulse Schedule level.
That feels like a lower level. Am I, is that.
Cassandra: that's fair and certainly I think reflects my own interests and where I'm sitting at the moment of that interoperability, that handoff between different architectures and everything like that. The pulses are exactly what you don't get to talk about when you're looking at something at that level of abstraction.
But, it's a very fair point, and yeah. I'm not personally involved with OpenQuasm 3, so I can't, do anything more on that than read the same documentation.
Sebastian: I guess to ask the question more generically. So if you think about the error we're in right now, before you get to an idealized machine that you can assume is fault tolerant in some way, you may have to,
Do special things to, to handle the types of errors that your particular JAR subroutines are going to encounter or whatever.
But there's a lot of capability in the platform itself right now. Thank you. You can think of all kinds of use cases where you may have to tweak at the lower level, like dynamical decoupling or something like that, right? There is, there are ways in which you can use control, the actual control, the direct metal control in in a, a quantum program as it exists today.
Is that something that QIR? Would be able to manage within its context, or is it out of scope for QIR?
Cassandra: the moment, my understanding is that is something that is out of scope for QIR, just because, to your point earlier about higher level versus lower level in terms of device, properties of the device are even looking at? buT, if that's there are ongoing QIR community calls and I hosted by the Unitary Fund, and it is really interesting to follow those discussions, because sometimes, you join one of those calls, and you start to see a shift in, oh, that's a use case that, we hadn't included as a community and what we thought an IR should look like, and you start to see the folks behind QIR adapt or in some cases, the QIR Alliance the members of the QIR Alliance have said in calls like that's a great use case, but it's probably for a different tool.
And in both cases, it really comes down to that letter I of intermediate. It's, I think one of the things that we've learned over and over again, as in a classical computing industry is. There's no one tool that can do it all and you know that's part of why we talk about non functional requirements like interoperability and
It's part of why we have words like non functional requirements,
Sebastian: Yeah.
Kevin: Yeah.
Cassandra: So it's I don't think, if a particular tool or protocol or format doesn't include a particular use case, that means that use case is bad or uninteresting or useless. It means. We're building a whole ecosystem of tools and they sit at different points in a stack.
Where exactly each thing should sit in that stack I think is very much an evolving conversation in the industry as a whole. And honestly it's really neat to see that happening and see all the different ideas put forward.
Sebastian: PUtting the, sort of the scoping, where in the stack this should reside, questions aside, because I think that is an incredibly interesting discussion, but to return to where you Are working in your consultancy, are you, do you see QIR in your work as a way to aim at the horizon when the customers you're working with can leverage the work you're doing with them to, run real quantum programs on a quote unquote, real quantum computer at some point in the future and not worry about the shifting landscape of the, the lower level of the stack.
Cassandra: I think for that I'll go to, my three key takeaways from, Quantum Week this year. Or a real increasing focus in fault tolerance, um, looking at where more and more tools can and more and more providers and languages, things like that can have a point of handoff so that, language designers don't have to.
There's a talk Natalie Brown gave that, had a really great slide that, what she called the N to M problem, right? If there are N languages and M service providers, you don't want to have to write N times M compilers. So I think the... That, my second sort of takeaway from conversations watching talks and what are people, what concerns do people have at lunch while, chatting about where the industry is really the need for having something like QIR.
And that QIR exists now, so hey, let's figure out the right ways to use it. My third takeaway of course was Covid which is why I've spent, the
Sebastian: Ha! Mine too! My unfortunate takeaway.
Kevin: Yeah, I think it's all three of us actually.
Sebastian: Had it almost exactly the
Kevin: Yeah.
Sebastian: Not from each other, I don't
Kevin: My god, but yeah, yeah, I wave hit. We all got it. Yeah.
Cassandra: So I think, somewhere that I am absolutely happy to talk to folks, and offer my services as a consultant is. If you're looking to understand what QIR is, where it could fit into your stack, or where the right point of handoff is. That's something where I'm absolutely happy to help have that conversation.
The sort of broad takeaway that I can offer, I think, that I think is really important is we're looking to, as a, as an industry and as a community, we're looking to really expand what we mean by what a quantum computer is from The state of the art experimental practice of 2017 to what we know of fault tolerant architecture looks like and that, we're starting to see that expansion now.
There are several entire workshop set and tutorials and tracks about that at QuantumLeak, and I think the volume of talks and Panels about fault tolerance really does speak to that shift as an industry. So with that expansion, we need ways of doing that decoupling, solving that sort of N to M problem that Natalie mentioned in her talk. And there, as I opened with, I think part of the art of building quantum computing out as an industry is being judicious about where we remember the history of classical computer science and adopt it and where we say, Hey, that really isn't the most useful thing for us to carry forward into something that looks different.
And something that we really have learned over and over again, we've been bitten by over and over again in the history of classical computer science is it map, having interoperable formats and protocols allows for decoupling things in really useful ways. If you're a language designer and you have new language ideas, the last thing in the world you want to have to do is.
Sit there and worry about every minute detail of a CPU, because now you've coupled those minute details and you've reduced the design space for processor designers, and vice versa. If you're a processor designer, the last thing you want to have to worry about is how that affects A particular high level language, like awareness and communication across is absolutely important.
But having a coupling where neither side can go pursue their own unique ideas without worry of breaking the other side. That's not an ideal state of affairs. And I think. It's not a coincidence that as LLVM has really exploded in the classical computer science world over the last bit over ten years, we've seen things like Rust come up as a language, and very quickly be able to target many of the same backends that LLVM can and similar languages that are LLVM based, but also that we've seen an expansion of what it means for A classical computer, uh, to be a classical computer that we have seen more use of
And FPGAs and ASICs and going up the stack with things like WebAssembly and, before that, ASM.JS. And the fact that we're seeing exploration on both sides of that stack is a result of having a good handoff. So I go to where do we need to be in quantum computing? We need to expand what our model of a quantum computer is. We need to get better at writing applications. We learn from classical computer science that the way to do that is decouple, so that the people who are coming up with better ideas for applications, the people who are improving the hardware, aren't stuck on, this kind of an end to end sort of coupling where we've taken dependencies on things that aren't that expansion.
Sebastian: That's really great.
Kevin: Yeah, it really is. Thank you for this overview of this highly complicated topic. And I, again, I think our audience, they said they pay such careful attention to these nuances of the developing tech landscape. So thank you for delving in deep on this important topic.
Sebastian: Yeah, appreciate your time, Cassandra. It's been a pleasure.
Cassandra: And it's been wonderful to be here. Thank you so much for having me.
Sebastian: Okay.
Kevin Rowney: Wow. That was really fun. Sebastian. Good times. The theme she brought up that was so powerful for me is, the immense history of all the trade craft and computer science and language design and operating, operating system design and how there are certain elements of that history and trade craft that have direct and powerful applicability to quantum computation.
And then there's other elements where, you know, who knows there could be . Brand new pivots, brand new new modalities of expressing that same trade craft. Really a cool topic. And I think a valuable one in terms of just seeing with more nuance and depth, some of the developments within this space.
Sebastian: Absolutely. Put your finger right on. Why I wanted to have Cassandra on, because
Kevin Rowney: Yeah.
Sebastian: it's one of the areas in which I see progress quantum information science, quantum computing. I. Into this space where it starts to intersect with traditional classical CSS and the 70 years of learning that we have in things like compiler design and
Kevin Rowney: Yeah.
Sebastian: solution architectures and all the rest of the hard problems that we've been tackling in classical information, classical computing, and more to the point. The modes of productivity, right? Open
Kevin Rowney: Yeah,
Sebastian: software development, the way in which you can marshal enormous population of very smart people in the world. She mentioned unitary fund being part of the alliance structure and helping bring people together around the development of QIR. That's just, we, we talked to Misty from unitary fund in a prior
Kevin Rowney: Yep.
Sebastian: I just think that. Everything that sort of falls into that space between classical software, open source development, and this new emerging space in quantum information science is the place I find the most exciting to watch.
Kevin Rowney: Fun times. Yeah. Really enjoyed that.
Sebastian: Kevin Quantum intermediate representation is what that acronym expands out to. This is a really interesting project. Open Source, open standard project. That the QIR alliance is driving that. Cassandra is one of the prime movers behind. And the work that they're doing is to create this intermediate representation that's meant to promote better portability of code in the quantum space.
And intermediate representation is a way to. Provide a middle ground, if you will, between the lower level of the stack, the hardware specific functionality, and the higher end of the stack. The higher level language is the general purpose language is things like python, rust, and the like.
So it's a really interesting topic. It's become one of the hot topics within the quantum information science community. And I'm really interested to hear more from Cassandra.
Sebastian: Welcome back. We are joined today by a special guest, Cassandra Grenade who an independent consultant in the quantum space with a quite an interesting professional path and academic career in their background. And Cassandra, would you mind thank you for joining us. Would you mind introducing yourself and give us a little bit idea of how you got to where you are today?
Cassandra: Absolutely, and thanks for having me wonderful to be here today. as Far as how I got to be where I am today, that's... That's always a fascinating question.
Sebastian: Isn't it?
Cassandra: I, and in part because I think I got to where I am, that followed the particular path I did by virtue of being very bad at making decisions about what I want to be when I grow up.
Kevin: Oh my
Cassandra: I go back to like undergrad and I did the very unusual thing of a triple major because I couldn't make up my mind whether to do math, physics or computer science. And seven years later, I never did make up my mind. And
Sebastian: to perfectly describe the intersection that you need for quantum information science.
Cassandra: Exactly. And it's where can I apply all three of these? This quantum computing thing looks pretty good.
Sebastian: So convenient.
Cassandra: Yeah, but so from there started with grad school at Perimeter Institute was one of the inaugural year of Perimeter Scholars, um, and that was really neat, had a lot of different perspectives that I wouldn't have ordinarily gotten, I think, coming through a Sort of quantum computing focused or CS focused or even pure physics focused.
It really was a lot more interdisciplinary
Kevin: Yeah. It sounds like a cool scene. Yeah, no
Cassandra: Yeah, absolutely Went from there to do my PhD at uwaterloo before doing a postdoc at University of Sydney And from there decided to come back to the US To join Microsoft, was there for about five, five and a half years and recently made the move to be independent and launch my own consultancy.
And that's been a lot of fun.
Sebastian: that's dual space, right? Is your consulting? Dual space solutions. Yeah. And is there anything in particular that you're trying to focus on with dual space or is it fairly broad or how would you characterize your offering?
Cassandra: My joke around that is always, my niche has long been not having a niche -- above about, being very bad at deciding what I wanted. That's all the cheeky and humorous way to put it, but the more serious answer is My strength across my career has always been taking an interdisciplinary approach.
Being able to find, what part of a problem is not being seen, what's missing, and try and go explore that part. And that's what I try to bring with dual space solutions as well is to not say define myself into a particular niche, but rather to be able to say if you have some broad strategic question, what are you missing?
If you're trying to look at some program as a whole, where are the parts where, maybe you're not taking into account culture and workplace or community, maybe you're not taking into account Some classical computer science, but that, there's a communications breakdown between the sort of CS or physics mindsets around things.
Kevin: Sounds really cool. I've done some of the solo consulting stuff in the past and it can be, a complicated thing to run. Respect that's impressive. , I was just wondering, Cassandra, could you give us a little bit more detail about the nature of some of your engagements that you're doing? It sounds really interesting.
Cassandra: it. Yeah, so it is fairly new so I've been doing this a few months as an independent consultant now. And I think where I'm most excited to look is... Collaborating, as mentioned around finding places where existing expertise at a company may not cover.
Everything and where I can try and provide some of that context and for that I do bring my PhD and postdoc were around software for statistical characterization. So QCVV, and that brought a lot of software focus to doing physics experiments. A lot of my work at Microsoft was, connecting research ideas to software implementations.
And that's the same kind of expertise that I bring now to solo consultancy work is trying to connect some of those two across. So I like it. It kind of discussion I really love having is, hey, here's an interesting research idea. How do we take and put this into software or here's some software?
What are we missing in terms of the research context in which software will be used? Or, here's some classical computer science idea. What's wrong with it about that, as we generalize that to quantum or alternatively and arguably more importantly, what's right? What do we not have to throw out about classical software history as we're coming to a quantum context? So I mean from all those different perspectives, what I'm really excited about working with, folks across the industry is finding places where those connections. aren't happening, or maybe they are happening, the outside perspective on the collaboration is still really helpful.
Yeah.
Sebastian: I joked about, that's the perfect sort of set of disciplines to intersect to create quantum computing but that is really true in a way. That interdisciplinary perspective is particularly valuable at this stage of an emerging technology when in large part we don't know what we don't know and it does, it very rarely is the best strategy to assume, based on priors, I know how to approach this problem and I'm just going to You know, weight in and treat it like, like previous contexts that I'm familiar with.
And often you need that kind of outside perspective, bringing in some unexpected viewpoint or some tool in the, that you are lacking in your toolkit. So that, that sounds like a really valuable approach.
Kevin: No doubt.
Cassandra: absolutely. And I think across the field, we are seeing a lot of places where that is necessary. There's also the opposite of, sometimes things are a little bit different in quantum and we need to know when to throw out bits of history, when to keep them. anD I mean that I think the two most dangerous things you can modes you can get into is Oh, quantum is just, like classical computer science, so we know exactly how to do that.
Or, quantum is nothing like classical computer science, so let's throw out everything we've ever learned. Eh, I know it's kind of cliche and everything to talk about how weird quantum mechanics is. I think it really isn't as weird as all that. There is a lot we can learn. But occasionally there are things that we really do need to rethink something classically. And the challenge is being able to really tell the two apart.
How do we be, how do we act judiciously and, really pick out the parts of classical computing history that are essential to keep that are really going to save us a lot of reinventing the wheel. And I'll say, I think that somewhere that like physics as a sort of curriculum, less than an industry, less than a discipline, if you talk about physics majors, that's somewhere where I think, A lot of students are really let down and it's causes a lot of reinventing the wheel.
Kevin: Yeah.
Cassandra: Throw out the wheel if it's not working I'm not trying to say we should be constrained by history, but if you don't know what you're throwing out and you're not doing it on purpose, then it's really easy to reinvent the mistakes instead of adapting to, your what's unique about your situation,
Kevin: So this is an interesting thread of conversation. I wonder, can we drill down? What major elements, our audience are many of them, really into tech or, that fast moving advances within the sciences. What elements of classical computing trade craft do you think are really important to preserve within quantum computing and what areas and traditions are just get tossed out entirely?
Help us see the landscape as you see it.
Cassandra: A lot of my PhD and kind of postdoc, if I go into a lab The vast majority of problems that I see people struggling with in a lab are software, right? Because, now, there's a giant caveat there. That's, some ten odd years ago and I think things have improved immensely since then, but it really used to be okay, if it's not a software problem, then the people in that lab are well equipped to solve it.
And so you see everything being a software problem, not because that's somehow more foundational or it's more fundamental, but because people have solved everything else and that's what's left. And it's a lot of... I think of the work I've done and language design and collaboration things like that, or, how much of just writing classical software comes down to string handling or writing, uh, boring sort of loading config files, saving config files, things like that comes down to managing your source code, with,
Things like Git, tracking issues, and that's a lot of the workflow that again, I think isn't really part of the physics
Sebastian: Right.
Cassandra: So it's always a stumbling block again when you get to, oh, hey, my job is now also software because I'm managing a lab or I'm trying to and so I think that is, and I, there again my comments are really about physics as a curriculum rather than physics as a practice, and where I think students encounter stumbling blocks and work through it, I don't know, you stare at any piece of software long enough and it's a string handling problem, whether that's star IDM on some GPIB connection or whether it's, try and export.
Plot and writing out graphics primitives, like you're still at some point doing the same sort of string handling that's been done since, well, computers.
Kevin: No doubt. Yeah.
Sebastian: And is that level of sort of abstraction from the perspective of CS that the discipline of CS, is that sort of where you came from when you started working on the subject I'd really like to dig into the most in a way is, which is QIR, the Quantum Intermediate Representation
Cassandra: Yeah,
Sebastian: Yeah.
Cassandra: so I really see QIR as a very radical attempt to not reinvent any more wheels. So if you talk about a what a quantum program is we've known since about 2005 as an industry since before, really, we thought of it as an industry, right? We've known since about 2005 that fault tolerant quantum computation involves a lot of conditioning quantum operations on the results of measurements.
And this comes about due to the demands of fault tolerance threshold theorem, that you're doing error correction, you're doing a lot of decoding, things like that. And there are certainly tricks and techniques, and we've learned a lot since 2005. I don't think fault tolerance in 2023 looks the same way it did in 2005.
But the piece that I think is really important that we carry with us even now is that quantum programs aren't circuits. Circuits are part of quantum programs. That you have also all of this rich classical logic going about. And decoders are... In general, fairly complicated compared to, the kinds of classical logic that we can write out with double lines and a circuit notation.
There's some pretty simple decoders, but even the simplest are still going to look complicated compared to that, the control flow that looks nice in a circuit diagram. And that, that really does say, all right, we need a way to write down what a. Quantum program is we know it has these classical elements.
And as soon as you get to that just throw out the quantum part It's hard to write down those classical processing elements People have tried for decades and decades to have you know a way of writing down A classical algorithm in some portable way,
The promise of write once run anywhere with Java.
The idea and there were
Sebastian: A triumph of marketing, you have to
Cassandra: I yeah, no argument, and that's even in a case where we're pretty spoiled by the fact that most classical processors look the same at the level of writing out, a block diagram and pseudocode. The details are incredibly important, but I can still treat mathematically, an ARM core and an x86 core as being roughly the same in terms of there's an instruction counter and a program counter and they proceed through, and it looks vaguely like a random access machine in both cases.
And at the level of, writing down what a classical program is, Those details matter a lot, but it means I can use the same kind of abstractment in both cases, and even there it's been a decades long problem
That out. aNd that's before I even allocate my first qubit, I have to have something that is at least as hard as this problem that's taken us, a few decades to have really good approaches on the classical side.
And so the kind of radical not reinventing a wheel is... Let's not do that. Let's just actually use the tools that the classical CS community has developed over those decades. There's no perfect solution, but that work pretty well at giving you portable representations of classical programs across different architectures and across different CPUs.
And, it's been neat looking at how much the LLVM project has done classically. And that it first off decouples the idea of what a language is from how do I reduce code down to a given processor? But making that step has also enabled some pretty surprising things like that You can target GPUs or FPGAs sometimes or even target things that just Would have been really weird to imagine at the start of LLVM like targeting web assembly I mean for a little while you could Look to things like in script and for compiling C to JavaScript, which feels exactly backwards, but was really useful in taking some legacy code and making it available for folks to use in the web browser driven world.
And that's the kind of really surprising reinvention that I think was enabled by having handoff between frontends and backends. So QIR really does build on that by saying. Look, we're going to, at some point, have to write down a classical program, whether it's a decoder, whether it's, some repeat until success algorithm.
So let's start with a baseline of something that can represent classical programs, and then build on top of that the things we really need for quantum.
Kevin: So this is such an interesting thread and, we're in some sense just hobbyists and not experts like you, but we try to get close as we can given our abilities to what's going on in these underlying architectures, but it will be surprising to hear from you that, that the diversity in quantum computing architectures can be sufficiently abstracted to fit into a broad enough framework.
I agree with you that different. CPU types in classical computing there's one abstraction that can cover, virtually all of them. Is it really the case then that the diverse array of quantum computing architectures can also be successfully abstracted?
Cassandra: There, we're saved again by, the fault tolerant threshold theorem, right?
Kevin: Yeah.
Cassandra: The whole idea of fault tolerance is, in some sense, is to abstract away what errors look like in your device. Thanks.
Kevin: Ah,
Cassandra: But that also means you're abstracting away the details of that device in particular and reducing it down to Instructions that are, part of your error correcting code and so forth.
That's part of why, things like the Clifford group has the importance that they do. is Because the role that they play in fault tolerant arguments and things like that.
Sebastian: So then are you saying that sorry, Kevin does that, am I right in? I'm thinking then that you're leaving fault tolerance, the task of fault tolerance to the QPU, and you're assuming that input is is these idealized circuits that will then be implemented at the hardware level in a way that that, meets the fault tolerance threshold in whatever way is appropriate on that piece of hardware.
Is that right?
Cassandra: I'm not saying that I'm in the, in particular, I don't want to make a statement at all as to what happens inside, a service provider in terms of how they take that. I know there have been talks, for instance, from like IBM, where they've shown a little bit behind where, they accept input and what they do with it.
And that does look, like you're saying, we've heard things like a successive lowering amongst different IRs, but, it's I'm certainly trying to stay gnostic on that and think from the standpoint of, what is a good point of. Where is it that we
Cassandra: Not specialize our languages, our compilers, our compilation passes and our optimizers and things like that to one service provider?
While still keeping the generality we need to really match, the, what we've learned from sort of 2005 era thinking together with what we've learned about the importance of near time again, to borrow IBM's terminology but to, the importance of near time processing adjacent to your quantum program.
Sebastian: Which goes back to your point about fall tolerance error correction. They're gonna need a lot of very tightly coupled quantum resources and classical resources to encode and decode and make decisions ba conditioned on the output of a prior circuit.
Cassandra: Yeah, and to take a little bit of a brief tangent by way of answering that, I think, where, we've seen a lot of really exciting things come out of near term quantum devices is when they teach us how to build better quantum devices. Now, there are many other exciting things about, I'm picking out the thing that excites me the most out of which is and so there, if you look at a lot of kind of near term algorithms, they have this flavor of do a thing classically, do a thing quantumly, do a thing classically, do a thing quantumly and, that there's this alternation between.
And the tighter you can make that alternation, the less times you're, making round trips back and forth with a service provider, and the better everybody's life gets. That's another mode of integrating classical and quantum computation that I think wasn't really obvious in 2005, early fault tolerance era.
But now is a feature that we probably will expect to see carrying forward to larger and larger devices, in addition to that tighter real time mode that you mentioned just
Sebastian: right
Kevin: Right. And just for the benefit of our audience, I could think of at least two examples where that classical quantum interchange is very common. One's, of course, the quantum variational eigen solvers, right? And the other is all of these interesting algorithms where classical compute capacities are being used to essentially tune a An error correction algorithm for quantum computation.
Are there other concrete examples of this sort of, for the benefit of our audience on this, classical quantum interchange, which have a broad application?
Cassandra: I do think, you called out variational algorithms like VQE. I think that is the quintessential place where we see that that alternation where there's classical. prOcessing that happens on a timescale that's long compared to qubit lifetimes. And then there's things that look more non adaptive within qubit lifetimes.
And variational there is the clue, right? It's the word that says, I'm minimizing a function. aNd everything about black box optimization and classical computer science. really need to know what thing I'm minimizing to have that sort of alternating structure of I make calls into this thing, I look at the value and use that to decide where I call it next.
Kevin: Yes. Yeah. Yeah. Makes sense. I gather there's probably also some, I think some quantum machine learning algorithms as well, that do a lot of that same kind of back and forth classical quantum alternation.
Cassandra: yeah, so certainly not trying to say it's exclusive, rather the opposite that I think, what we see. In what I think we really learn out of variational algorithms, um, and again, there's many exciting things, but the thing that, excites me when we're talking about stuff like QIR is like okay, what do we need to take with us as we build larger devices, as we build toward fault tolerance and, the insight that yes, we have classical computation happening both at time scales that are long compared to qubit lifetimes and that are short compared to qubit lifetimes.
And we need some uniform way of representing both of those.
That's... That's the insight that I think is really important there and really interesting when we're looking at both sort of 2005 style arguments, what we've learned about variational algorithms since 2016, and where we would like to be as we build out fault tolerant devices as an industry.
Kevin: And I have to agree with you, it really is a fascinating question and really at the outer limit of skill sets of two separate professionals who are well known for their IQ and their energy. Amongst physicists, quantum computing is a no mess around subject, amongst computer science people, compiler optimization is also the deep end of the pool.
You're doing like two, two hard things. And it at the same time with this rather ambitious project.
Cassandra: Yeah it's been a challenge in classical computer science to say, let me write down... A description of a classical program that doesn't depend deeply on the details of any particular processor so that I can lower down to a processor, um, as a next step, that if I look before LLVM and things like LLVM, I think now LLVM has won out in some pretty significant Parts of that space, if I look before that, or at least before it was clear that LLVM was a good sort of industry consensus, I, if I have some processor that I want to run things on, I have to pick a language that is supported on that processor, right?
Rather than saying, Hey, I want to write a program and I want to use a processor. And the thing is, that's how the world looks. Now, today, in classical computer science, if I look at embedded devices,
So my partner and I as a hobby, we, like instrumenting our house with like different CO2 sensors or putting telemetry on our boat and things like that.
And a lot of that is writing things, for different ESP32 microcontrollers and stuff like that. And if you look at microcontroller world today. There isn't such a thing as the C language. There's the C language as this microprocessor, or sorry, microcontroller company implemented, and the C language as this company implemented.
And the idea of C being a standard is unheard of. They're all like, weird quirks about whitespace formatting that depend on and it's okay, I get the details between these different microcontrollers matter, but I didn't think whitespace was one of them, right? But it just comes along for the ride.
Sebastian: string manipulation again.
Kevin: Yeah.
Cassandra: So if you're writing a compiler for, your bespoke microcontroller and you're starting these days, it probably is going to look more like taking something like LLVM and writing a lowering step from LLVM IR to the things that make your architecture unique than starting with let me first write down what a string is, and I think that's where we really can learn a lot from classical computer science history there.
And why, I think QIR is as exciting. yEah, there's a lot of differences between different quantum architectures, but there's also a lot that is in common.
And trying to start by abstracting over the commonality that we can,
Sebastian: Yeah. If I could take another another tag, like when you, so OpenQASM is the existing, I would say probably most used, most leveraged OpenStandard for representing primitives on a QPU, right? The circuits, the gates when you compare QIR to OpenQASM, is the, does the difference boil down to exactly what you said before that, that fault tolerant quantum computing, In 2005 was a, there's a different understanding of that topic than there is now, and QIR incorporates our new understanding of that, that topic compared to OpenChasm, which is a 2005 version of what that, that looked like.
Cassandra: So I'm going to give two very different answers to that because it depends highly on whether you're talking about OpenQuasm 2. 0 or OpenQuasm 3. 0. I really think those are very different topics as far as that's concerned. anD we'll give you very different answers to that. And the 2. 0 case, that's some OpenQuasm 2.
0 is a great language for writing down circuits with little to no classical control. Things that where the most complicated classical control you get look something like teleportation or things like that. But where I can't really do anything like a while loop, right? That you might expect out of, say, a repeat until success algorithm. There have certainly been extensions to OpenQuasm 2 that try to allow that. There had, you can take and loop unroll. But then you're paying a lot of overhead and propagating through those controls. And you have to have a very small finite number of iterations that you can consider. And it composes really badly to do everything loop unrolled.
So OpenQuasm 2, it's a great language for writing down quantum circuits that are either entirely non adaptive or have very little classical adaptivity. With things like OpenQuasm 3. 0, we're starting to see, again I think that industry can sense this, that we need a lot better representation for classical control reflected there as well.
But, where I see... Where I'm both excited about OpenQuasm 3 and where, I do disagree with it some, I think OpenQuasm 3 is a great high level quantum language. I don't think it's really what we want out of an intermediate representation. And the reason why is there's a lot of great high level things like, looking at taking powers of a gate or looking at adjoints of a gate or controlled operations and things like that are exactly the kinds of conveniences you want in a higher level language to be able to efficiently write out quantum programs, but are exactly the kind of overhead that you don't want to think about if you're taking a already compiled quantum program and lowering it down to the specifics of a particular piece of hardware.
And that's fine. Like that's in fact, the whole sort of game that we're trying to play here as an industry is how do we take and abstract out the things we can abstract out and focus, tools on the things that they're really good at, so to my mind I really seeing OpenQuest in 3 as a high level language,
I think, it is, it's great to see that there are more and more high level languages, Um, that do in fact have the capability for expressing some fairly sophisticated classical control algorithms.
We see OpenQuasm3, we see Qsharp, we see CudaQuantum. There is a talk at Quantum Week about RiverLane, sorry, Xanadu's work with RiverLane along those lines. And it was great to see that talk. And then that, to my mind, increases the need to have some common sort of intermediate representation.
If I'm, a researcher working on, some neat new circuit optimization technique, the last thing in the world I want to do is have to think about all of the nice high level features that OpenQuasm 3 provides its users to be able to write out programs by hand. I just want to know...
Excuse me. This is the list of actual operations
And that, that looks a lot more like an IR and I think that's part of why, you start to see stack and OpenQuasm 3, I think, could be a part of that stack. I, but I think, if we're looking at intermediate representations that can handle the requirements, we know both from current near term devices.
And from the sort of 2005 era fault tolerance arguments that have continued through to today, QIR is what we've got. There aren't really alternatives that deal with that at the moment. iF there are alternatives that are developed, that's awesome. I don't think it's one of those where, um, the first thing that we think of is always, the best or what'll carry on for decades.
But right now, if you're looking to develop tools that can act on quantum programs in general, then I think QI HR is looking like a really good choice for that. And I think that really opens the design space for languages. I hope we'll see more. I mentioned four different ones there. I hope we'll see more, use the fact that, QIR does offer that nice point of handoff
And start to really see more exploration of the design space for quantum programs that can include classical adaptivity.
Kevin: This is just great detail. Thank you. And help bottom line this for our audience. In terms of the ultimate effect on the overall ecosystem of coders and, theoreticians and so forth that use these systems, where do you see the primary expression of... of traction of benefit of the QR system.
Is it developer productivity? Is it compiler optimizations? Is it, better interchange and portability? I'm not sure what's the primary effect.
Cassandra: It's hard to talk about all, any of those without acknowledging or, giving voice to, I think the biggest one of it just changes what we mean by what a quantum computer is. To look a lot more like the sort of scalable devices we hope to build instead of the devices, the really exciting devices we've been able to build for the past almost 10 years that have taught us an immense amount that we've been able to do a lot of really cool stuff with, but maybe don't have all of the Architectural details that we expect things to eventually look like, um, so I mean it's productivity and portability and interoperability are all things that I think are really great to have on the forefront of our minds, but there's the even more exciting thing to me of.
We're just changing what a quantum device looks like as an industry, as our consensus sort of shifts and our capabilities and is an industry evolve to look more like what we need out of scalable, practical quantum devices.
Kevin: And so more specifically, that means you, you believe, I'm guessing deeper and richer expression of error control and error correction and the, these hybrid classical and quantum computing capacities more deeply integrated. Is that
Cassandra: yeah, so we, I think there's. At this point, a lot of good understanding at, a mathematical level, at a practical level of having tried it and seen where it got us. Quantum programs do not look like circuits. Circuits look like subroutines in
Cassandra: That doesn't mean circuits are bad, circuits are useless.
Circuits are great, but they're subroutines. They're not programs.
Sebastian: Yeah.
Cassandra: And having something that includes everything we've learned about pure circuits and can put that into the context of a full quantum program. That's the kind of infrastructure and that's the kind of architecture we need to keep going.
Sebastian: aNd help me with something else, because I, this is probably my mistaken framing, but OpenPulse was released with OpenChasm3, and it feels like OpenPulse is a lower level construct than what you're talking about. When you said OpenChasm3 is a high level language, I get it on the circuit and gate description level, but on the pulse Schedule level.
That feels like a lower level. Am I, is that.
Cassandra: that's fair and certainly I think reflects my own interests and where I'm sitting at the moment of that interoperability, that handoff between different architectures and everything like that. The pulses are exactly what you don't get to talk about when you're looking at something at that level of abstraction.
But, it's a very fair point, and yeah. I'm not personally involved with OpenQuasm 3, so I can't, do anything more on that than read the same documentation.
Sebastian: I guess to ask the question more generically. So if you think about the error we're in right now, before you get to an idealized machine that you can assume is fault tolerant in some way, you may have to,
Do special things to, to handle the types of errors that your particular JAR subroutines are going to encounter or whatever.
But there's a lot of capability in the platform itself right now. Thank you. You can think of all kinds of use cases where you may have to tweak at the lower level, like dynamical decoupling or something like that, right? There is, there are ways in which you can use control, the actual control, the direct metal control in in a, a quantum program as it exists today.
Is that something that QIR? Would be able to manage within its context, or is it out of scope for QIR?
Cassandra: the moment, my understanding is that is something that is out of scope for QIR, just because, to your point earlier about higher level versus lower level in terms of device, properties of the device are even looking at? buT, if that's there are ongoing QIR community calls and I hosted by the Unitary Fund, and it is really interesting to follow those discussions, because sometimes, you join one of those calls, and you start to see a shift in, oh, that's a use case that, we hadn't included as a community and what we thought an IR should look like, and you start to see the folks behind QIR adapt or in some cases, the QIR Alliance the members of the QIR Alliance have said in calls like that's a great use case, but it's probably for a different tool.
And in both cases, it really comes down to that letter I of intermediate. It's, I think one of the things that we've learned over and over again, as in a classical computing industry is. There's no one tool that can do it all and you know that's part of why we talk about non functional requirements like interoperability and
It's part of why we have words like non functional requirements,
Sebastian: Yeah.
Kevin: Yeah.
Cassandra: So it's I don't think, if a particular tool or protocol or format doesn't include a particular use case, that means that use case is bad or uninteresting or useless. It means. We're building a whole ecosystem of tools and they sit at different points in a stack.
Where exactly each thing should sit in that stack I think is very much an evolving conversation in the industry as a whole. And honestly it's really neat to see that happening and see all the different ideas put forward.
Sebastian: PUtting the, sort of the scoping, where in the stack this should reside, questions aside, because I think that is an incredibly interesting discussion, but to return to where you Are working in your consultancy, are you, do you see QIR in your work as a way to aim at the horizon when the customers you're working with can leverage the work you're doing with them to, run real quantum programs on a quote unquote, real quantum computer at some point in the future and not worry about the shifting landscape of the, the lower level of the stack.
Cassandra: I think for that I'll go to, my three key takeaways from, Quantum Week this year. Or a real increasing focus in fault tolerance, um, looking at where more and more tools can and more and more providers and languages, things like that can have a point of handoff so that, language designers don't have to.
There's a talk Natalie Brown gave that, had a really great slide that, what she called the N to M problem, right? If there are N languages and M service providers, you don't want to have to write N times M compilers. So I think the... That, my second sort of takeaway from conversations watching talks and what are people, what concerns do people have at lunch while, chatting about where the industry is really the need for having something like QIR.
And that QIR exists now, so hey, let's figure out the right ways to use it. My third takeaway of course was Covid which is why I've spent, the
Sebastian: Ha! Mine too! My unfortunate takeaway.
Kevin: Yeah, I think it's all three of us actually.
Sebastian: Had it almost exactly the
Kevin: Yeah.
Sebastian: Not from each other, I don't
Kevin: My god, but yeah, yeah, I wave hit. We all got it. Yeah.
Cassandra: So I think, somewhere that I am absolutely happy to talk to folks, and offer my services as a consultant is. If you're looking to understand what QIR is, where it could fit into your stack, or where the right point of handoff is. That's something where I'm absolutely happy to help have that conversation.
The sort of broad takeaway that I can offer, I think, that I think is really important is we're looking to, as a, as an industry and as a community, we're looking to really expand what we mean by what a quantum computer is from The state of the art experimental practice of 2017 to what we know of fault tolerant architecture looks like and that, we're starting to see that expansion now.
There are several entire workshop set and tutorials and tracks about that at QuantumLeak, and I think the volume of talks and Panels about fault tolerance really does speak to that shift as an industry. So with that expansion, we need ways of doing that decoupling, solving that sort of N to M problem that Natalie mentioned in her talk. And there, as I opened with, I think part of the art of building quantum computing out as an industry is being judicious about where we remember the history of classical computer science and adopt it and where we say, Hey, that really isn't the most useful thing for us to carry forward into something that looks different.
And something that we really have learned over and over again, we've been bitten by over and over again in the history of classical computer science is it map, having interoperable formats and protocols allows for decoupling things in really useful ways. If you're a language designer and you have new language ideas, the last thing in the world you want to have to do is.
Sit there and worry about every minute detail of a CPU, because now you've coupled those minute details and you've reduced the design space for processor designers, and vice versa. If you're a processor designer, the last thing you want to have to worry about is how that affects A particular high level language, like awareness and communication across is absolutely important.
But having a coupling where neither side can go pursue their own unique ideas without worry of breaking the other side. That's not an ideal state of affairs. And I think. It's not a coincidence that as LLVM has really exploded in the classical computer science world over the last bit over ten years, we've seen things like Rust come up as a language, and very quickly be able to target many of the same backends that LLVM can and similar languages that are LLVM based, but also that we've seen an expansion of what it means for A classical computer, uh, to be a classical computer that we have seen more use of
And FPGAs and ASICs and going up the stack with things like WebAssembly and, before that, ASM.JS. And the fact that we're seeing exploration on both sides of that stack is a result of having a good handoff. So I go to where do we need to be in quantum computing? We need to expand what our model of a quantum computer is. We need to get better at writing applications. We learn from classical computer science that the way to do that is decouple, so that the people who are coming up with better ideas for applications, the people who are improving the hardware, aren't stuck on, this kind of an end to end sort of coupling where we've taken dependencies on things that aren't that expansion.
Sebastian: That's really great.
Kevin: Yeah, it really is. Thank you for this overview of this highly complicated topic. And I, again, I think our audience, they said they pay such careful attention to these nuances of the developing tech landscape. So thank you for delving in deep on this important topic.
Sebastian: Yeah, appreciate your time, Cassandra. It's been a pleasure.
Cassandra: And it's been wonderful to be here. Thank you so much for having me.
Sebastian: Okay.
Kevin Rowney: Wow. That was really fun. Sebastian. Good times. The theme she brought up that was so powerful for me is, the immense history of all the trade craft and computer science and language design and operating, operating system design and how there are certain elements of that history and trade craft that have direct and powerful applicability to quantum computation.
And then there's other elements where, you know, who knows there could be . Brand new pivots, brand new new modalities of expressing that same trade craft. Really a cool topic. And I think a valuable one in terms of just seeing with more nuance and depth, some of the developments within this space.
Sebastian: Absolutely. Put your finger right on. Why I wanted to have Cassandra on, because
Kevin Rowney: Yeah.
Sebastian: it's one of the areas in which I see progress quantum information science, quantum computing. I. Into this space where it starts to intersect with traditional classical CSS and the 70 years of learning that we have in things like compiler design and
Kevin Rowney: Yeah.
Sebastian: solution architectures and all the rest of the hard problems that we've been tackling in classical information, classical computing, and more to the point. The modes of productivity, right? Open
Kevin Rowney: Yeah,
Sebastian: software development, the way in which you can marshal enormous population of very smart people in the world. She mentioned unitary fund being part of the alliance structure and helping bring people together around the development of QIR. That's just, we, we talked to Misty from unitary fund in a prior
Kevin Rowney: Yep.
Sebastian: I just think that. Everything that sort of falls into that space between classical software, open source development, and this new emerging space in quantum information science is the place I find the most exciting to watch.
Kevin Rowney: Fun times. Yeah. Really enjoyed that.
