Okay, we'll go ahead and get started. Good afternoon, everybody. My name is Quinn Bolton. I am the quantum computing and semiconductor analyst for Needham and Company. Welcome to the 21st annual Needham Technology Media and Consumer Conference. We're pleased you can join us. It's my pleasure to host this fireside chat with Horizon Quantum. The company recently came public in late March. We're going to have Dr. Joe Fitzsimons, co-founder and CEO, or founder, excuse me and CEO Joe will walk through some introductory slides and then we'll come back for our fireside chat we also have CFO Greg Gould and Catherine Balin handles investor relations here in the audience with that I'll hand it over to Joe and then we'll come back for the fireside chat portion of the talk
Thanks very much. Thanks for joining us. So I wanted to talk a little bit about what we're doing at Horizon. Since it's our first quarter as a public company, I wanted to give a bit of a flavour of what we do. And specifically what we do as a company is to try to deal with the fact that no computer that is out there is really effective without software. And quantum computers are not any exception to this. So there's been tremendous progress that has been made over the last year, 18 months, in getting towards quantum computers that can actually do useful work. And we're getting to the point where we're starting to see the first claims of solving really hard problems using quantum computers for the first time. But they're still not at a mature stage. They're still not at the point where software running on quantum computers in production is affecting the bottom line for companies using those systems. And what we're focused on is getting there. So our mission at Horizon is to build a software infrastructure that enables developers to take advantage of quantum computers to solve hard problems, to produce software that generates real value for the end users of that software. And now, in order to get there, we have to deal with several different things, right? There's a lot of software infrastructure that needs to be built on. But you can think about where we sit in the quantum computing ecosystem. Well, at least I like to think we sit at the heart of the ecosystem in the sense that we are connecting three of the major groups in that ecosystem. We're connecting developers to hardware providers and to end users through our software infrastructure. So by that, what I mean is we are building the programming languages. We're building the compilers to be able to take code written by a developer and compile it down into a form that we can then compile further to target any one of the wide range of quantum computers that are out there today. And we're then able to wrap up that quantum program and expose it as a web API so it can easily be baked into user-facing software. Now, in order to do that, you know, the reason we're doing this is we're going to overcome one of the major problems in quantum computing. So if you think about it, quantum computers, there are promises to be computers, but with an extra trick. So there are promises to be better computers. Unfortunately, there's two different things you need to do. First of all, you need to be able to build systems that can actually process information as quantum states. And that's really, really hard. That's a major challenge. And you see a lot of companies working on that in the hardware space, trying to build systems that can represent information using quantum states and manipulate it using quantum mechanics. Because we know if you can do that, we know there are certain hard problems you can solve much, much, much more efficiently than you could with a conventional computer. The other problem you have, though, is how do you take advantage of such a system to tackle a specific problem? And the reality of the situation is that there are several major barriers to doing this. So the first is that quantum computers work in a different way than conventional computers. They have to be able to harness this quantum effect of interference between different possible branches a computation could take in order to extract information about the results for those different branches in order to be able to get any kind of a speed up compared to conventional computers. So if you're not harnessing this particular quantum physics effect in your computation, you're not having any advantage over running on a conventional computer. And the reality is, this is just non-intuitive. Humans don't have a natural intuition for how quantum mechanics works. We don't experience it in our day-to-day lives. So the way we think about solving a paper, maybe with pen and paper, maps pretty well to how conventional computers work. It doesn't map at all to how quantum computers work. So if you look at the number of people that have had any success in terms of being able to build quantum algorithms, being able to construct the kinds of algorithms you need to run on these systems to harness those effects, the number of people that have done it more than once is like 250 people worldwide. It's not a large number of people. And one of the reasons for this is it takes a long time to get any good at this. You have to build up experience by basically failing 99 times before you succeed once. So then, you know, if you're a glutton for punishment, you do it all over again. The other problem you have is that quantum computers are really diverse at the moment and imperfect. So you have a wide range of different underlying physical systems, everything from photons to trapped ions, neutral atoms, superconducting systems, silicon, quantum dots, and so on. And each one of these systems behaves in a different way. Their architecture is different. Their instruction set is different. And if you want to take maximal advantage out of the system in front of you, you're almost certainly writing code that is tied very directly to that one particular hardware system. And so it isn't portable. And the third problem you have is that, you know, the programming languages lack abstraction. So the programming languages we use to program quantum computers today, it's basically like machine code. we're piecing together programs one logic gate at a time. Now, maybe we're using the machinery of Python to do that to get more efficient. And you certainly see a lot of frameworks out there that allow you to do this in Python and make use of Python loops and so on. But the reality is there's no abstraction there. You're still thinking about how you can construct your program one logic gate at a time. So if we want to get to a place where quantum computers are solving hard problems in production, creating real value for the end users of those programs then it's not just a hardware problem software is also a big part of getting there um what we're trying to do at horizon is to essentially build a bridge between classical software and by classical i mean anything that's not quantum so between conventional software and accelerated implementation on quantum computers now if we want to do this there's a lot of technological challenges we need to overcome along the way so first we need to be able to take a program written for a conventional computer we need to be able to break apart the things that make it slow, the loops, the recursive function calls and so on, break them into simpler and simpler parts we need to recognize which each one of those parts is doing and then we need to replace it with a more efficient means of doing the same thing and if we do that and those replacements we're making when I say replace with a more efficient means of doing the same thing I mean using some kind of quantum processing to do this then we can get to a point where we have a quantum algorithm for that task But that has come from code that is written for a conventional computer that expects the niceties and the capabilities of modern computers. And although the promise of quantum computers is to be better computers, the reality is they're currently worse computers. So that means that a lot of the systems today are not able to do things like simple loops. They're not able to repeat instructions again and again until a particular condition is met. So what we have had to do is to build up the programming languages that target ideal quantum computers. We've had to build up the compiler infrastructure to take those programs, compile them down into something that you can run on real systems today, and build up the execution stack that extends the capabilities of those systems in order to be able to more closely mimic an ideal system. So that lower part of that, going from a high-level description of a quantum program all the way down to deployed program as a web API, that's in triple alpha, our software today. We work primarily with the hardware companies, so this is only an early access, it's only a small user group, it's not generally available. But what this allows users to do is to build much more complex quantum applications than it would otherwise be possible, and to compile them down and execute them on a really wide range of quantum computing hardware. So what we're doing is essentially removing the need for developers to bet on which technology is going to win. Again, you can write the code in our languages and you can make it run on basically anything. We're not just a thin software there. We're actively extending the capabilities of the systems we run on. So that means if you think of things like loops, if you think about things like dynamic memory allocation, you think about things like being able to measure a qubit in the middle of a quantum computation and do something with the result, that is largely not supported on many of today's quantum computing systems. But when you access those same systems through our software, you are able to do that. So we're really extending the capabilities of what developers are able to do with these systems. We're also, I think, the first hardware, sorry, the first software company in the world, or first quantum software company in the world, to start operating our own quantum computing systems. We have a superconducting system based on a Rigetti processor that is currently up and running in Singapore, in our headquarters there. and we've just announced plans for a second system, a trapped ion system from IonQ. Being able to work this close to the hardware allows us to tightly integrate with the control systems, which is really necessary to be able to extend the capabilities of these systems to have that tight integration to actually get to a real advantage. If you need to go through many software layers on the way down, it adds a lot of bloat. It's very difficult to get to a real advantage at this time where the systems are only just on the cusp of being able to solve hard problems. The highlights for the last quarter are several fold. We've added additional hardware partnerships. As I said before, we focus on working with the hardware companies. We've recently signed agreements with Alice and Bob and with AQT, which is AQT some of you may have seen announcements from over the last few weeks where they have an as-to-record quantum volume. We've also been expanding our testbed system. So our first testbed system based on that superconducting system, that superconducting chip from Rigetti is up and running at our offices in Singapore. And we have signed an agreement at the end of the quarter to purchase a 256-qubit system from IonQ that we expect to have up and running sometime in 2027. The other side of this is we have focused heavily on moving up the stack in terms of the technology development, building out our languages to introduce a first object-oriented programming language called Beryllium. We showed Beryllium in preview back in December. Over the course of this quarter, we've really been extending the capabilities of that, getting ready to open it up to external users. Just to show you what a quantum computer looks like, obviously, it's always lit in blue and green like this because, you know, you wouldn't want to light a lab any other way. This is based on a Maybel refrigerator, which you can see there, and we have a Regretti processor inside it. The control systems come from a company called Quantum Machines. We have also, as I said, now ordered this system from IonQ, which will add a second testbed system for us. Now, the real advantage of doing this, and you might say, well, how many systems do you need? The reality is you can divide basically all quantum computers into two categories. You can talk about solid state qubits, which tend to be manufactured systems. They're kind of engineered systems. You're maybe making a superconducting processor by etching it, and so on. So you've high control over the parameters, but there's also high variability between different devices. So These things tend to need to be extremely cold, so you need a dilution refrigerator like I showed you in the last slide. You tend to need microwave control and so on. But then there's the second category of qubits, and I'll call them AMO qubits, but these tend to be atomic molecular optical physics. So these are things like trapped ions or neutral atoms or photonics. Their structure is dictated by nature, so it's not flexible. well, you can't engineer it, but at the other side of this, every single one of them is identical. You know, a cesium atom is identical to every other cesium atom. And, you know, typically these things require things like optical stability and high vacuum and so on. So there's a separate set of facilities requirements you need to care about for these. So with the introduction of our second testbed system, we now have coverage one testbed system of each type. So it kind of lets us learn the lessons to be able to host and operate quantum computers of more or less any kind. So I will leave it there and I'll, you know, finish up, but I just want to leave you with this. What we're doing is to try to build the software infrastructure that we believe is critically important to enabling a broad quantum advantage, to enabling developers to take advantage of quantum computers to solve hard problems across industries. And we're doing this in a way that's hardware agnostic from the perspective of the developer. So the developer does not need to make a bet as to which system is going to win out in the end. Instead, they can write their code in our programming languages and then compile it and run it on whatever hardware system is most appropriate for that task. And lastly, we're a software company, so our economics look just totally different than that of the hardware companies. You know, our capex is much lower. We would expect our margins to be very much different. Thanks very much.
Great. We'll start with the fireside chat person now, and if we do have questions from the audience, just raise your hand, and we can take those questions for Joe. But Joe, thank you for the very comprehensive overview of the company and sort of where you play in the quantum software infrastructure. I guess for folks in the room who may be newer to quantum or just trying to get a high level of overview of quantum programming and how it's done today. Can you start with, you know, before Horizon, how were quantum computers programmed through frameworks like Qiskit or CERC and what are some of the disadvantages of those frameworks currently?
um so the most common way to think about programming quantum computers that's quite prevalent at the moment and has been up to now is the idea of quantum circuits and this is a little bit like uh and something like an integrated circuit right you're thinking about piecing together logic gates um in this case quantum logic gates but they're similar to piecing together the nand gates or something like that you would use in conventional computing and so what you're thinking about is how do I implement my piece of software by writing out a pattern of logic gates that gets me to a solution. So this is really like adding together an AND gate where if these two bits are both one, then the output of the AND gate is one. But if one of the input bits is zero, then the output of the AND gate is zero. So you're thinking how do I piece together primitives like this? They're a little bit different for quantum computers, we have things called CNOT gates and so on. But it's very much a similar vein. And so what you're thinking about as you program quantum computers in these frameworks like CERC and so on is how do I piece together a program logic gate by logic gate that gets me to a solution? Now, of course, that's very painful if I have to write out all the logic gates. So what has happened is that you have the emergence of these Python frameworks that allow you to use the machinery of python the loops and python and so on to piece together these circuits in a you know in a kind of mechanical way uh so you can say well keep adding keep adding and gates to the circuit until this condition's back and that you know that is a way to build circuits that can run on these systems but there's a few limitations first of all not all of computation is circuits. The programs running on your laptops now, almost none of them can be expressed as a sequence of logic gates. And the reason for this is that they contain things like indefinite loops. They contain while loops where it repeats some set of instructions again and again and again until some condition is met. And actually it's really famous in, there's a famous problem in computer science called the halting problem, which kind of the premise of this is that it is undecidable whether a general computer program halts or not. So you don't know how long the runtime is going to be. And if you take away the halting problem, you say I'm going to build only things that I know when they halt, then you're essentially restricting to circuits. And that's what's happened in quantum computing to date. We've tried to go a different way. We've tried to go beyond circuits. We've tried to say, what can an ideal mature quantum computer do? Then can Can we design programming languages that target that ideal perfect future quantum computer? Can we build the compilers that lower them down to target different kinds of systems? But can we build the runtime capability, the execution stack, to be able to take that program written for an ideal future quantum computer and run it on today's quantum computers? And normally what we have to do there, when I said we extend the capabilities of hardware, what we're doing is we're making multiple calls to hardware systems. So we're doing multiple different quantum computations and stitching them together with conventional compute to give the effect of a single run on a much more capable system. Now, with our testbed system in Singapore, we're able to extend those capabilities of the hardware system so we can go beyond circuits and start to do real-time execution where you do have things like while loops and so on. But for us, that's kind of critically important in getting to really useful quantum computing. we kind of see it as having to speed run the history of computer science. So with beryllium, where we've gotten to object-oriented programming, I'd say we've gone from 1940s to 1980s. So I guess we still have some way to go.
My next question is triple alpha. One of the key features of triple alpha is your layers of abstraction to sort of mask some of the complexities of the hardware and requiring the programmer to understand quantum mechanics. And so maybe spend a minute talking about the benefits of abstraction and how you achieve that through triple alpha.
Yeah, so the way we have approached this is that ultimately we want to get to a place where the developer does not need to understand quantum mechanics at all in order to be able to program quantum computers, in order to be able to get the benefit from running on them. But that's a challenge, right? Because fundamentally, you need some kind of algorithm that exploits quantum mechanics in its processing in order to have any advantage at all from running on these systems. So the way we have approached this is we have started from this kind of very low-level, gate-level and below it, and started to build up programming languages that move further and further away from the low-level physics and more towards how you manipulate different kinds of information. So what we have done with Beryllium is to essentially build an object-oriented quantum programming language. The basic idea here is that because developers can start to create classes to represent different kinds of information, it allows them to build up higher and higher levels of abstraction. Within our own compiler, we have hydrogen that is like an assembly language. That's kind of 1950s technology. We have helium that sits above it. That's an imperative language. It's a little bit like a quantum version of the basic, so solidly 1960s technology. And then beryllium sits above that, which basically we have built these up to be able to get to higher and higher abstractions ourselves. But as we have gotten to beryllium, this kind of object-oriented language, so maybe solidly 1980s technology, what we are allowing is developers to build classes to represent different kinds of information, so vectors, matrices, graphs, whatever it happens to be, to build them to describe how that information is stored and represented as a combination of quantum and classical information, but then to make those available to other developers or to really use them themselves such that now the developer only needs to import that library and they can suddenly start to work just with that information type. So if you've built a library that allows you to represent matrices and vectors, another developer can import it. They can work just say, okay, I'm going to define a vector. I'm going to define a matrix. I'm going to start multiplying them together and so on. And that allows me to build machine learning algorithms or whatever on top of that. I can build a new library that allows me to do machine learning algorithms, for example. And so each time a developer builds a new library, it kind of builds a new abstraction that is available to all other developers then. And that gives you a kind of leveraging up where each developer can build higher and higher level of abstraction, but allows each developer subsequent to them to do more with less code. So, you know, hopefully it's unlocking a fairly strong network effect, but it's really the reason that Python is so popular. If you look at its prevalence today, a lot of that is due to the strong library ecosystem and the fact that each new library is essentially extending the power of the language.
Got it. Ultimately, or one of your ultimate goals with Triple Alpha is to quantum accelerate any code written classically. I believe this will be that layer that will ultimately be called carbon. Can you walk us through sort of the process of how do you break down classical code, find those portions that can be quantum accelerated, and then rebuilding up a program so it's quantum accelerated?
Yeah, sure. So, I mean, back in 2019, we kind of laid out this path with hydrogen, helium, beryllium, and then carbon. And so, you know, we're on step three or four at this point. At the level of carbon, what we are aiming to do and what we've been able to demonstrate in kind of standalone demos is the ability to automatically construct quantum algorithms from code written for conventional computers. And the way we approach that is we say, well, what makes the code slow? And the things that make the code slow tend to be things that cause instructions to be repeated many times. And there's kind of two kinds of things that do this. One is loops. So you have a while loop or a for loop that just iterates through the same instructions again and again and again and again. Or you have recursive function calls. So you have a function that calls itself and the whole thing telescopes out. So you repeat the same instructions again and again and again and again and again. So what we do is we try to break these apart. So we might have several nested loops. We try to break apart the instructions with inside those to make more and more and more loops, but each one of them simpler than the loop we started with. So we try to break these apart. I mean, technically, it's called fissioning loops, but we try to break these loops apart into simpler elements. So now we have just a loop that maybe only has an if statement inside it. And so we know it has no effect unless the condition in the if is satisfied. And it turns out we can replace that with a quantum algorithm that does the same thing. We can use a quantum search algorithm, a kind of quantum linear search, to search for the first instance in which that if condition is satisfied. And what that allows us to do is to start to piece together a quantum algorithm, an algorithm that is exploiting quantum information processing to get to a solution more efficiently than you could with conventional processing. And the reason we're doing this, not trying to just generate a solution straight from the start is because if you are hired to go into a company as a consultant and try to construct a quantum algorithm for a particular task, the smartest thing you can do on day one is to say, how do you already solve this problem? So if you start with code that already gets to a solution and you make transformations that only make the code more efficient, then you're guaranteed more or less that the solution you generate is at least as efficient as the solution you started with. And that's generally not true with quantum algorithms. So the particular approach we're taking is kind of ensuring that we can always accelerate code where those accelerations exist.
Excellent. I wanted to shift to triple alpha. We talked about sort of the ability to develop programs, the various layers, but an important feature of triple alpha is your runtime kernel that can reside on a piece of quantum hardware and almost act as the operating system. So maybe if folks aren't familiar with what an operating system does for a classical computer, start with what's the role of an operating system and what's the opportunity to get your runtime kernel on quantum hardware.
So, I mean, the way programs work on conventional computers, the programs don't really run in isolation. They're running alongside system software that is running on your computer and that's providing various services to those programs that are running. So an example of this is something called dynamic memory allocation or dynamic memory management. So within your laptop, within your iPhone, whatever it happens to be, you have some amount of computer memory. And that is being used by different programs all of the time. And within those programs, as they're executing, they may need space to store variables. They almost certainly do. Almost every instruction needs some space to store something. And you need to manage what space is free and what space is used on the device. And each program can't manage it alone, otherwise you would have to divide up your RAM into dedicated blocks for each program. And you don't know how big they're going to be, you can't make good use of your RAM. Instead, you want the operating system to manage that, to see, okay, what blocks of memory are available when, so that a program can request memory to store variables. And if you don't have that, you end up trying to pre-allocate all of this at compile time. So you end up trying to assign where you're going to store all of the information right at the development time, and the reality of that is it's horrifically inefficient. You would just use much, much, much, much, much more memory than you need. And the current situation with quantum computing is that we are getting to quantum computers that have literally hundreds of bits of memory. That's the current state of the art. It's not terabytes of memory, it's not gigabytes, it's not megabytes, it's not kilobytes. It's barely bytes. So we're at this point where it is critically important to manage this as well as possible. So what we have had to do is to build up these capabilities that normally system software on your laptop would take care of for you, because we want to get to a point where we can take programs written for conventional computers and run them on quantum computers. So we need to start filling in these gaps. We need to start adding these capabilities to manage the execution of the programs to provide the services to them as they are running in order for those programs to take best advantage of the hardware. So we have put in a lot of effort to build up that side of things. But at the same time, in order to implement a lot of these, you need quite advanced execution capabilities. You need to be able to do classical compute at the same time as quantum compute is happening. And in order to do that, what we do is we generate code directly for the control systems so that we're storing that classical data on the control systems as the quantum program is running and so that we can inject it directly into the program. You know, we have this kind of interacting classical and sorry, classical and quantum computation that are going on at the same time. And that is not where most quantum computers are today, at least through the public APIs. You're much more restricted to only being able to execute, you know, circuits which are basically lists of instructions that end in measurement. So by being able to extend this kind of execution infrastructure, it allows us to unlock a lot more and start to get us to the place where it makes sense to start talking about kernels and about operating systems, about quantum system software in a way that really hasn't made sense up to now. I mean, the term operating system is used quite often in quantum computing, but usually people just mean an orchestration platform where you're queuing up jobs or something like that. I'm really talking about something fundamentally different. I'm talking about what, you know, the role DOS plays or the role Linux plays in running conventional computer programs.
And on that front, how do you see the quantum industry developing classical computers? You've tended to have one OS that's dominant across multiple hardware platforms. You look at, you know, sort of MS and DOS and over on PCs. Do you think the quantum industry ultimately moves that direction or is it going to be very fragmented where each hardware vendor ultimately tries to develop its own version of an operating system or at least partners for it?
I think you can look at what happened in the history of computing. I mean, in some sense, I think there's a very direct analog between the way conventional computing evolved and the way quantum computing is evolving. And, you know, the early days of conventional computing, OSs were built by the hardware manufacturers. It was very fragmented. There was no compatibility between systems. There was no portability, really. And then you started to see, you know, you started to see operating systems emerge with some level of compatibility across systems, with, like, System 360 from IBM and stuff like this. And I think that is the path that quantum computing is on. The reality is that there is no one dominant hardware player at the moment. There are very many different hardware efforts that are credible. There are at least four distinct paths to building large-scale error-free quantum computers, based on photonics, based on neutral atoms, based on superconducting qubits, and based on trapped ions. And each one of these, there are multiple players that are trying to pursue different architectures within that one modality. And I think that's really a moment of opportunity for a company like us, because it allows us to provide an abstraction layer that insulates developers from having to guess which one is going to win out, and from having to have to redevelop their code for each new system that comes along or as they move between different hardware platforms. So I think, although there is an argument that if a single player became totally dominant, that they would want to have their own software stack that would be the end state. But the reality is the ecosystem is very fragmented at the moment. And that means that if a software layer becomes dominant at this point while the ecosystem is fragmented, even if things consolidate, even if the hardware side consolidates to a single player, that software there that is already being used by developers that's already creating a lot of value and that's getting more out of that hardware is going to be in place. It's going to be pretty strongly entrenched. Yeah, so I think that's how things are likely to play out.
Excellent. I wanted to shift gears to sort of the go-to-market strategy, how the company intends to generate revenue on a go-forward basis. And I think there are two primary channels. One is sort of usage-based access. through APIs that call specific quantum computing resources. The other is sort of, as we just talked about, sort of more serving as the operating system for on-premise deployments. And so maybe talk about those two channels.
Sure. Yeah, absolutely. So what I would say is that the nature of our tools is that when you write programs in our languages, they are deployed to our deployment infrastructure, executed to our execution stack. that kind of necessarily means that every time a program produced with our tools is used it is going through our infrastructure that kind of puts us in a similar position to where AWS is with web apps that every time you build an application it is calling our infrastructure and that puts us in a position to charge based on usage and based on the value of the resource being accessed So I think that has proven itself to be a pretty strong model in other places in computing that has shown up. But at the same time, I want to be clear that we are really focused at the moment on getting to a real quantum advantage, that our focus is on enabling advantage so that developers can actually build applications that really generate real value in the real world. and that means that our focus is on technology development and on integrating hardware partners at the moment rather than on driving revenue and it's going to stay that way until a real advantage starts to emerge because the reality is that's the step change that the entire industry is waiting for. The industry just looks completely different before and after quantum advantage, at least in my view.
I think you mentioned that one of the reasons you're not pursuing near-term revenue opportunities like proof of concepts, is so that you can focus on enabling the capabilities.
Absolutely. You turn into a consulting company otherwise, right? You can certainly drive revenue through professional services. As I said, one of the ways to try to get to quantum applications that have some kind of advantage is essentially through consulting. You have a room full of quantum computing experts and you go out to industry and you say, tell us about your hard computational problems and you bring them back and you try to solve them. And that's, you know, maybe that works well for certain high value problems and so on. But our focus is on trying to automate that process. Because if that process is not automated, it's a massive bottleneck for the adoption of quantum computing. It's really going to result in much slower adoption than if we can automate this process. Because by automating it, we make it possible to harness quantum computing to solve a much wider variety of problems. We just make it much more applicable.
Turning to sort of one of the questions that we've had from investors, just sort of the competitive landscape. You have hyperscalers like Google, Amazon, Microsoft trying to develop their own software platforms, I think taking advantage of their web access or their own quantum computing services. You have NVIDIA with CUDAQ. what are the pros and cons of those approaches versus Horizon's approach?
Yeah, so I think the way we approach things is fundamentally different. So most programming approaches that exist to date for quantum computing have kind of co-evolved with the quantum computing hardware. So that means kind of exposing capabilities of hardware as they have emerged. We've kind of gone the other way around. So what does an ideal quantum computer look like? How do you program that ideal quantum computer? And then how do we take that code and execute it with today's systems? And that necessarily means that we're exposing capabilities that are just not possible with these other approaches. One of the key things that we are enabling by going to a kind of object-oriented approach to quantum programming, which I realize is deeply technical, but the reality is that if you try to piece together quantum functions, You say, okay, I'm going to build a functionality that does search, and I'm going to build a functionality that does Monte Carlo methods, and I'm going to build a functionality that does factoring or whatever, and I'm going to stitch them together with classical compute, which is the way most of these other frameworks have been approaching this. You lose out on something. You lose out on the ability to have compounding speedups. So, for example, you might imagine you have a problem where you try to find, for example, mispriced derivatives. So you're going to search over the different instruments, you're going to search over hedging strategies, and then for each one of those, you're going to use Monte Carlo to price it. Now, if you stitch together your quantum search functionality with your quantum Monte Carlo functionality with classical compute, you will get a square root speedup for that problem. If you are able to construct a larger quantum program that uses quantum Monte Carlo, the quantum Monte Carlo algorithm, inside a quantum search for the hedging strategies, inside a quantum search over instruments, you can improve this to not just a square root speedup, but to a square root of a square root of a square root. So you can get to much larger speed-ups if you are able to build these larger, more complex quantum programs. And that's where we're focused. I would say it significantly distinguishes us from other approaches.
Excellent. We're down to about the last 30 seconds. So, Joe, maybe for those in the audience tracking the company, what are some of your biggest goals or what milestones should folks be looking for from the company, say, over the next 6 to 12 months?
Yeah, sure. So at the moment, what I would say, like a major focus with us, we've shown Beryllium in preview back in December, we will start to get that available to early access users in our system and start to build up the library ecosystem around it so that developers are really able to get kick started with building larger, you know, with building further and further abstraction there. So we really start to kickstart that effect. The other thing I would say is that you will see our testbed. We have the first testbed system up and running. We will start to integrate that. Well, we are working to integrate it with Triple Alpha at the moment. We'll start making that available to early access users too. And then you'll start to see the, well, you know, you'll start to see the second testbed system start to be installed. the capabilities of that system are such that it should be you know if it lives up to spec it should be just on the cusp of a real quantum advantage so it should be just about you know whether it will be perfect what it will be capable of actually realizing a quantum advantage or not it's not yet here but it is right on the cusp so that's gonna be a very exciting time for us I think
excellent well Joe thank you very much for joining us at the Needham conference We really appreciate it. Thank you.