Cloud Hosting

Joe Fitzsimons, CEO of Horizon Quantum Computing, is interviewed by Yuval Boger. Joe describes the companys approach of building software development tools that aim to accelerate classical code and make it run more efficiently on quantum hardware. They discuss the advantages and disadvantages of abstraction layers, the potential for quantum computing in chemistry, and much more.

Yuval Boger: Hello, Joe, and thank you for joining me today.

Joe Fitzsimons: Thank you very much. Very happy to be here.

Yuval: So, who are you, and what do you do?

Joe: Im the CEO of a company called Horizon Quantum Computing. Before I started Horizon, I was a professor of quantum computing for nearly 20 years now. At Horizon, were focused on building software development tools to make it easier to build programs that take advantage of quantum computing.

Yuval: At a high level, there are several companies that build software for quantum computers. What makes Horizon unique or what makes your approach unique?

Joe: The approach weve been taking is to recognize that its going to be very hard to take advantage of quantum computers if you dont have a really in-depth knowledge of quantum algorithms and how to construct them. If you look at the numbers, really only a few hundred people do have that kind of level of knowledge. So what weve been doing is trying to build up tools to make it both easier to program the systems from a technical point of view, being able to do more with less code, but also being able to enable domain experts to take advantage of quantum computing in different domains like finance, pharma, but also things like the energy sector, automotive, aerospace, and so on. For us, what that has meant, our kind of North Star, is that we are building towards being able to accelerate classical code, code written to run on a conventional computer. We want to be able to take legacy code, code that has been written for systems that have nothing to do with quantum computing, and make it run faster on quantum hardware.

At the moment, I think were probably the only ones that have capabilities in that direction. Weve put quite a lot of effort into being able to, for example, accelerate a subset of MATLAB code: to break it apart, automatically construct quantum algorithms from that classical code, and then, the intention is to be able to compile that all the way down to run on hardware. Now, where we are at the moment, the first tools youll see coming out from us are a little bit lower down the chain than that. We have tech demos. You may have seen us at Q2B last year, for example, or the year before, where weve had demonstrations of accelerating MATLAB code. But what our focus is on right now is getting to early access with our integrated development environment that allows users to program at a somewhat higher level of abstraction than existing frameworks, but still not quite with classical code. What that means for us is programming in a quantum programming language that looks a little bit like BASIC. We call it Helium. Its fully Turing-complete, so youre not programming circuits, youre writing programs that may have some indefinite runtime. And youre doing it in a way where you can write subroutines, for example, in C or C++, and compile those directly down to extremely efficient quantum circuits. So thats kind of what weve been building. Its coming up to early access now, so therell be more updates at Q2B this year.

Yuval: If I were to play devils advocate on abstraction layers, I would say that abstraction layers are the best way to get code to be equally bad on all hardware platforms. How do you respond to that?

Joe: I think with a smile. So in some sense, youre right. And if the approach we had been taking was to, for example, build up libraries for optimization algorithms or something like that, then I would 100% agree with you. But thats not what were doing. And were not focused on those kind of black box algorithms. Rather, were focused on the way conventional compilers work. So we are taking source code and building an optimizing compiler that not only does the classical optimizations but also does quantum optimizations on the way down to construct a quantum program for the same task. At every layer its passing through, it is getting optimized for the processor closer and closer and closer to the hardware. So weve had to put in a lot of effort. Weve built an entire stack. We dont rely on any of the existing frameworks at any point in our code. So going from C or going from Helium, compiling that down, that process that it goes through, everything from the constructing quantum circuits to converting between instruction sets, doing the gate synthesis, compiling down to target particular hardware, and also taking things that are maybe loops, like while loops and things like this, that you cannot run on current hardware and turning those into hybrid programs all of that is us. So were doing all of this without any other quantum computing frameworks in there except when it comes to export time. So if you want to export in QASM, for example, to target an IBM system or something like that, then, of course, we give you framework code that you can run on an IBM system. But all of the generation behind the scenes, thats not based on any of the existing frameworks or anything like that. So weve built our entire stack to go the whole way down.

Yuval: If we look at one of the biggest computing revolutions, that was the transition from CPU only to CPU plus GPU. And when you look at a GPU, it is programmed similarly but still different than a CPU. You have to think about the cores; you have to think about some local processing and so on. So, what have we learned from that transition from CPU to GPU, and how does it apply to the QPU transition?

Joe: Thats a great question. So what I would say is that theres different ways you can think about this. If you are a developer working at a low level with GPUs, for example, then you need to be writing GPU-specific code. If you are trying to implement faster linear algebra algorithms, you need to be very close to the hardware. If however, you are writing machine learning models, you dont need to worry about the GPUs. Not really. You just work within whatever Python libraries youre working in, and its taken care of for you. So there are different layers of abstraction going on in the classical world as well.

Weve been building our system in such a way that it has kind of layered abstraction. At the lowest layer, you can work directly with the hardware, with the native instruction set for it, constrained by the connectivity graph of the hardware and so on. But you can also work at a layer that is hardware-agnostic, where you can write kind of general-purpose quantum assembly code but that also allows for arbitrary flow control, loops, and so on, which can then be compiled down to target particular systems. Or you can work above that. You can work with Helium and with subroutines written in C and C++. And where were going is were going to classical code. Therell be several other layers above where were currently at. The intention here is that depending on your expertise, depending on the place youre contributing, you can dive in at whatever level of abstraction you want, make changes at that level of abstraction, develop at that level of abstraction, and leave all of the other layers as automatically compiled. So, if youre a quantum algorithms designer, maybe you dont want to be all that close to the hardware. Maybe you want to be a little bit higher up in the abstraction layers but not so high that its classical. You still want to be doing your quantum Fourier transforms and having full control over the system. If youre working on quantum error correction, you may want to be a little lower down the stack. And if youre a domain expert in the oil and gas industry, for example, then you probably dont want to deal with quantum code at all. So weve been trying to build a system where there is the flexibility to dive in at the layer that you care about, the layer that you can contribute at, and leave whats below it automatic so that you do not need to worry about those lower levels of abstraction.

Yuval: Lets talk a little bit about marketing this platform to customers. When you go to customers, I mean, I think its easy to get into the technical details. Well, what would you say are the top three benefits that a customer would have with your platform? Is it hardware independence? Is it the ability of non-domain experts to code? Is it something else? How would you pitch this to customers?

Joe: Sure. What I can say at the moment in terms of how I view the market is that actually, what is critically important at this point in time is technical lead and getting to quantum advantage as soon as we can. For quantum advantage, talking about approaching particular customer groups on what we can do for them, what everyone can do for them is extremely limited. Until were at a point where quantum computing is affecting these customers bottom line, its going to significantly affect willingness to pay, but were not really contributing to them. So really for us, our goal is to get to useful quantum computing as soon as possible.

In terms of what makes our system different, why we think it contributes to that goal, it starts to allow new capabilities that are not possible in existing frameworks, and it starts to make it much easier to do quite complex things. If you want to program a really large quantum program, and I would say the largest ones weve explored so far have been at the range of about 50 trillion gates, then there are not very many options in terms of how you develop that kind of complex software. So weve been trying to build a system that is capable both of developing for systems today, but also far into the future, so that were building a framework that will stand the test of time and that starts enabling new capabilities. For example, within our system, its very easy to make programs that have indefinite runtime to directly simulate a quantum Turing machine, for example. And that is just something thats extremely difficult. If you want to do it, just construct it from scratch as some kind of hybrid program, unless you have mid-circuit measurements, its not really going to be possible. Unless you think about how to do it with postselection and all of these other things, for us its trivial. You express it in our language. We just write a repeat until loop, and its going to run through that loop until it sees a particular value from a measurement and it will stop. ven though not all hardware can do that today, we compile that down to a hybrid program. And thats completely abstracted from the user. They dont need to worry about that hybrid program. It already converts it to do the postselection for you to run it as a series of circuits rather than a single circuit and so on.

So I would say, a big part of what weve been doing is ease of use, ease of writing more complex systems. This is true both from the development perspective, but also from the deployment perspective. For us, the end point of compilation should be a deployed program. It shouldnt be a single shot run or 10,000 shot run or whatever it is on that piece of hardware. It should be an API that the user can call with whatever inputs are used to describe that problem that will run the code on whatever hardware backend that has been compiled for and return the results to the user through a standard API interface so that they can build whatever frontend they want to process their results in whatever way they want. So if they want to incorporate it, they dont need to be working in Python. They can incorporate it straight into JavaScript. They can incorporate it into MATLAB. They can incorporate it into whatever technology theyre building.

Yuval: How does the platform deal with hybrid algorithms where part is classical and part is quantum? Do you expect users to use your quantum version of BASIC to write hybrid algorithms as well?

Joe: What I would say is theres perhaps two different categories that you can fall into here. There are hybrid algorithms where youre thinking about doing many different shots. You have some classical logic that is processing the statistics from the previous set of shots, that were run to determine the next circuit to run. And this is the variational algorithms that were all very familiar with at this point, I would say. But also, if you think about things like error correction or anything like that, you also need to think about classical processing that is happening concurrently with the quantum circuit. And thats somewhat different because your classical processing has to be able to feed back into the circuit. That means thinking about code that is running maybe locally on FPGAs rather than a nearby GPU system or something like that. We think about both within our system, how this is built. There is a simple way to implement basic functions classically concurrently with your quantum algorithm, but youre also able to include classical code that computes classical functions that run in a sandboxed way. That allows for the development of both types of algorithms, but importantly, it allows for the development of these more advanced algorithms where you need concurrent classical processing happening live with the quantum processing thats going on, which is clearly something we need as we move to fault tolerance, as we move to more complex quantum programs. Now, if you talk about how you would you do a variational Eigensolver or QAOA or something like this, what I would tell you is that our system is really designed for programming the quantum backend. By the quantum backend, I mean the quantum processor itself, as well as any classical control that sits with it. Its not intended for running large compute loads. Its intended for very fast functions. So its intended for pure quantum backend development, but what you would do if you were developing a circuit, we have a way of specifying inputs to be read at call time. So what you would do is you would specify each of the parameters that can be varied within your circuit as an input. You would compile that program and deploy that program with those inputs marked. And then from your front-end code thats implementing stochastic gradient descent in whatever framework you want, whatever technology you want, whatever hardware you want, youre implementing that, calling this API in the background with the specified parameters. Now, I will freely admit our system has been built to target more structured algorithms. My view has always been that theres unlikely to be a big advantage in NISQ, except perhaps for chemistry. Now, I could be proven wrong, and I am not saying that it is not worthwhile for people to be exploring variational algorithms. Its just personally, I dont think thats the direction of the future, and we have never been working toward that goal. You dont see Horizon QAOA or Horizon VQE implementations. Thats not our core competency.

Yuval: You mentioned getting to quantum advantage, and some people talk about the quantum equivalent of the GPT moment, where all of a sudden its clear that theres something there for general use. What is that going to look like in your opinion, and how soon will it come?

Joe: Thats a tricky question, and I dont think anyone really knows the answer to this. What I think is pretty clear is that the first real advantage is likely to be seen in chemistry. There are numerous reasons why you would believe this, but one of them is just that chemistry looks a lot like whats happening in a quantum computer. Theyre both quantum mechanical systems, theyre both obeying the same equations. You might also think that you can get away with a higher error rate for chemistry calculations if you can make the errors in the quantum computer look a little bit like the noisy environment that a molecule is experiencing. You may not need to cancel out noise, it may just be a process of shaping the noise to look like the natural world because the natural world is just not that clean. But yet chemistry works even in the complex environments of the real world. So thats why I think there will be a first narrow advantage for chemistry.

But for us, we also need to care about getting from that first narrow advantage to a broader-based advantage, where you start to see an advantage across a large number of applications. And I think a lot of it depends not just on hardware advance but also on advances in algorithms and advances in dev tools. You can of course, speculate what timelines look like on this, but what I would say that is maybe not so obvious is that were in an interesting time now where it is both advances in hardware and advances in software that can independently lead to a real-world quantum advantage. We seem to have convincing arguments at this point that there are at least a small number of quantum processors that are hard to simulate. With that being the case, the fact that we cannot yet make use of them to do real work means there are a couple of possibilities. Either theyre not capable of doing real work, but that could be because theyre easily simulable. But if theyre not simulable, then why cant they do real work? Maybe thats just a gap in our understanding. So advances on the algorithm side can help bring us closer there. Some of that will be theoretical advances on algorithms, and some of that will be advances in compilation where we are just getting better at harnessing those systems, getting better at echoing out the noise, getting better at taking the problem we care about and making it as small as we possibly can. At the same time, advances are happening in hardware. So youve got these two things that are going on in parallel. Over the last year, weve seen quite a few interesting demonstrations and quite a lot of progress around error correction and fault tolerance. Its clear were getting much closer to the goal of seeing a real proper demonstration of complete fault tolerance where youre doing useful computation, youre getting a performance that is improved compared to the physical qubits and so on, and where that encoding as it grows suppresses error further and further. Weve seen all of these components demonstrated individually, and in many cases, weve seen collections of these demonstrated. So were still just getting there to the first real fault-tolerant quantum computers. You can see that starting to be on the horizon, even if there are only two-qubit systems, three-qubit systems at first.

Yuval: Going back to customers, when you go to customers today with the products that youre releasing that are now available for early access, do you tell them, hey, you could run this? Have you done benchmarking? I mean, have you published benchmarking? Can you say, well, you can run this, this code is faster with our framework, or is it that this algorithm is much easier to program this way? Lots of customers use Qiskit, and so I think thats sort of their frame of reference. How do you compare to what theyre using today?

Joe: So look, Id say theres two different ways you can make comparisons. But the correct point of comparison for us I do not think are other quantum programming frameworks because were enabling functionality that is just not possible within those frameworks. For a start, those are our circuit frameworks. They generate circuits that run, you get results back. They dont generate Turing machines. They also dont have the capability of compiling classical code. So theres not really a place where I can compare our performance on C compilation to anything else. There have been a couple of demonstrations where you see people maybe implementing a unitary that implements some small function written in Python or something like that, but those are usually using cosine-sine decompositions or something like this, which are exponentially bad. To give you an idea of how well weve been doing in terms of generated C, we tried a couple of problems. We talked about this, Id say, maybe two years ago at Q2B. You may remember that Goldman Sachs had a paper out on options pricing, maybe, I think, 2021. The hard part of that, the bottleneck in that algorithm using Monte Carlo methods, is actually just a classical computation, a classical subroutine that computes e to the minus x. So theres an analysis that they did in terms of how many T gates it needs, how many Toffoli gates it needs. There was a subsequent paper about a year later that showed improved results. We tried compiling this from about 15 lines of C. So, we just implemented that inverse exponential in a fixed-point manner. Okay, theres some boilerplate code as well, but its about 15 non-trivial lines of C. We compiled it through our system with our default settings. What we found was that we outperformed the code that had been in both papers by a large margin, and in some parameter ranges up to a factor of 112 times in terms of the reduction of the number of T gates, or Toffoli gates. So this is a really large difference in performance.

For the actual number of gates for the level of precision involved, its pretty close to the square root of the number of the original gates. So were clearly getting good performance out of this, but its also limited by how good your C algorithm is. So if you use good C code, its better than bad C code. But thats a classical problem. So we have a lot of trade-offs you can make, and some of these do extremely well. So we have, for example, special constructions that we can use if were targeting low-depth circuits or low T-depth. So we use different constructions for different types of gates. If youre using it as part of an oracle, then again, we use special constructions that take into account that the phase thats incurred on each of the computational basis states doesnt matter because youre just going to compute this thing; youre going to do some controlled operations of it, and then youre going to uncompute it. So were trying to take into account these kinds of optimizations, and were trying to come up with the right kind of structures for being able to actively reuse qubits, for example, uncomputing them, making use of them again, recomputing things, and so on. As you can imagine, thats a fairly complicated process, but weve been getting good performance out of it.

In terms of what benchmarks will look like overall, as I say, were about to start early access. Well start seeing some examples there of how this looks like applied to real code. But what I can say is that there really arent good points of comparison in terms of other quantum frameworks because what were doing is quite different from what many of the other frameworks are doing.

Yuval: And as we reach the end of our conversation, I wanted to ask you a hypothetical. If you could have dinner with one of the quantum greats, dead or alive, who would that person be?

Joe: So Ive been really fortunate. Ive worked in this area for a long time. So Ive had dinner with some really impressive people over the years, with Artur Ekert, with Anton Zeilinger, with Frank Wilczek, with quite a few very eminent physicists. And I guess if it was allowed to pick someone from the past, maybe it would be Richard Feynman or something like that. Not just because of being a great physicist, but because I think hed be quite funny at dinner, and I kind of appreciate that in a dinner companion. But if were looking to today who it would be, then I have two answers for you. One is whoever runs @QuantumMemeing on Twitter. Because, again, Id like a bit of humor with dinner. I think thats, you know, I kind of enjoy that. And the other is Ewin Tang. So Im not sure if you know Ewin. I think shes a postdoc at Berkeley at the moment. But shes had a huge string of incredibly impressive results on the theory of quantum computing, particularly in relation to dequantization of machine learning algorithms. I think she thinks about quantum computing in a different way than I think about quantum computing, and I think Id have something to gain from being more exposed to that. Ive never met her before, so I think that would be beneficial.

Yuval: Excellent. Joe, thank you so much for joining me today.

Joe: Sure, no problem. Thanks for having me. Thank you.

Yuval Boger is the chief marketing officer for QuEra, the leader in neutral-atom quantum computers. Known as the Superposition Guy as well as the original Qubit Guy, he can be reached on LinkedIn or at this email.

January 1, 2024

See the original post:
Podcast with Joe Fitzsimons, CEO of Horizon Quantum Computing - Quantum Computing Report