Quantum Computing: Timing is Everything

Editor's Notes

• #2: Title: Timing Is Everything. ? I’ve spent much of my career delivering(?) bleeding-edge hardware from the lab in a way that delivers routinely usable high performance. At times I’ve been an individual contributor, as with parallel processing in UNICOS and graph-analytic kernels in Urika/SPARQL, and sometimes I’ve led projects, as with distributed memory in Cray T3D and T3E systems, distributed shared memory with Altix UV, graph analytics with Star-P, or now quantum computing with D-Wave’s … unusual processor architecture. So it’s with both perspectives, a technologist and a project leader, that I think of where we are going over the next two years with D-Wave systems. Whenever I prepare for a presentation like this, I ask myself what I could say that you, the audience, might want to hear. I looked over today’s agenda and quickly realized that many of the other QC speakers are technologists with deep understanding of quantum physics, understanding that I will not have now or in the near future. What am I going to say that will compete with that deep understanding of quantum physics? And then I realized that we’ll just be giving different types of presentations, given the different maturity levels of our technologies. My colleagues will speak of the enormous challenges facing them to build QCs that remain coherent, correct errors, and have enough qubits to be useful; with time horizons of 10-20 years, it’s appropriate to focus on the technology. D-Wave systems, on the other hand, have matured to the point where I believe we have a fighting chance to deliver differentiated performance on some real-world apps with our next-gen system, so I am here to talk about how we will deliver that, and how you and your org can join that first wave of success.
• #3: “Computationally differentiated”: your advantage compared to your competition is that you do computing better “appropriate high-value apps”: appropriate meaning ones that can plausibly get differentiated performance, high-value meaning it’s going to be a lot of work to get the performance, and you’ll want it to be for an app you care about “mapping to D-Wave systems”: this often requires serious thought, esp. to get good performance. This is usually at least as difficult and time-consuming as the shift to distributed-memory algs in the 90s. “compelling perf adv in 2y”:
• #4: I’ll cover these 4 topics in my talk:
• #5: GMQC Call out that Microsoft’s technology is expected to avoid EC issue QA We at D-Wave believe that our systems are moving much closer to the point of delivering differentiated performance and making people who deploy systems, like most of you here, care about them.
• #6: And it’s not just us. Researchers at Julich, one of Europe’s most respected HPC labs, have been evaluating QC systems for the last several years, and they recently published this QTRL scale and their view of today’s reality. They show the experimental qubit devices at a QTRL of 3-4, the IBM and Google systems at a QTRL of 5, and D-Wave’s quantum annealer at a QTRL of 8, defined as “scalable version completed and qualified”. The thing that remains for us to do is deliver differentiated performance….
• #8: ***NEED TO SAY “QUBO” HERE Use analogy here: think of a qubit like one end of a see-saw, which can either be up (1) or down (0). When you put a positive weight (e.g., sand bag) on the see-saw, the end goes down (0). When you put a negative weight (e.g., helium balloon) on the see-saw, the end goes up (1). This sampling turns out to be high value …
• #9: … as exemplified by this plot. We can think of the energy landscape represented by the QUBO as having peaks and valleys. We’ve found that one of the strengths of our quantum processor is its ability to find all the valleys effectively, due to the quantum effects it exploits. This plot illustrates that, with the X axis showing the cumulative annealing time, on a log scale, and the Y axis showing the fraction of valleys seen on a linear scale. For problems created to fit our topology, our 2000qb processor is about 1000X faster than the best classical solver. Notice I’ve used several caveats, but that’s 1000X faster. The Cray-1 was 10-100X faster. The T3E was sometimes 50-100X faster. 1000X faster is a big number. And, on real-world problems, that aren’t created to fit our topology, we lose a ton of efficiency, and find in general that we have rough parity for hard problems; sometimes 10X slower, sometimes 10X faster. To state the obvious, a quantum performance advantage will be delivered only from problems or subproblems that fit on our quantum processing unit or QPU. That doesn’t mean app developers are limited to that size, because we have a solver that decomposes a big problem into subproblems that can fit the QPU. Let’s look more closely at how the size of problems solved by our QPU will grow with our next-gen system. (after last) Noting that execution time for a quantum-machine instruction (QMI) is expected to stay the same or shrink
• #10: Today, in practice, problems of about 64 variables fit on the QPU. Our next-gen system is targeted to have 4-5K qubits with a denser topology. I expect the increase in qubits itself to increase the size of the QMI by a factor of 1.4-1.6. The denser topology increases it by a further factor of 2.8, with the added benefit of also improving performance due to shorter chains. We’ve gotten huge increases in our last few system generations from better control of the annealing cycle, for example a factor of 1000 by effective use of the per-qubit advance/delay feature, but there’s nothing about such improvements that we’re prepared to divulge publicly at this time. We also are seeing tools getting better, with one particular recent feature increasing the size of the QMI by another factor of 1.3. When we aggregate these changes, which are multiplicative, we see that the size of the typical QMI increases by a factor of about 5.5, from 64 variables to about 325. Very simplistically, the power of a QPU increases with the number of qubits in the exponent, so this is a huge increase. Rather than thinking of it as abstract computational power, maybe it’s better to think of problems that are tractable at 64 variables and intractable at 325. An example of that is Markov networks. Will all this increased power be delivered just as I’ve laid it out here? That’s unlikely, but I think this is a plausible range to expect. 2^64 to 2^326; the 5.46 is really an exponent; the power of the DW2K^5.46
• #11: ***DW2K connectivity v IBM 50qb cxnty (5x10 array) Putting on my technologist hat for a moment, there are major technical challenges to delivering this processor. Increasing the #connections/qubit by 2.5X is a major change to the qubit and coupler. Increasing the fraction of valid results, notably by reducing a particular source of noise, is another challenge we must meet to deliver this potential performance. To step back a bit, we continue to find that the value of the QPU is maximized when quantum tunneling, the ability to go through peaks instead of over them, is maximized for as long as possible. We also have challenges to understand the best use of further controls we’ve added to the annealing cycle. Despite all these challenges, we have a 500qb prototype working today, which gives us confidence we can deliver the full projected capability.
• #13: OK, let me put back on my project-manager hat and look at how one might adopt QA technology rationally.
• #14: I often think of probabilities with a log scale where only half orders of magnitude matter. Putting that in the context of technology adoption, 1% or 3% are pretty unlikely, so monitoring is sufficient. At 10%, I want to be monitoring the technology fairly closely, because if it jumps up to 33%, our org needs to be prepared, by which I mean understand the technology in depth and having hands-on experience with likely first uses. For the 50-100% probability range, I mirror the log scale of the bottom half. At 67%, I need to ensure our org is fluent and the first use case is readily deployable. At 90%, I want to have multiple use cases ready, and at 99-97% I should be disseminating our early expertise to other parts of the org for further use cases. My personal opinion is that we’re in the 33% range for our next-gen system delivering differentiated performance, so if I were in a techAdoption role I would want to be well prepared. What does that mean? What steps do we take to integrate a D-Wave system into a workflow?
• #15: So a rough sequence of steps to integrate D-Wave execution into a workflow looks something like You’ll want to become familiar with QUBO formulation. You don’t need to do it all at once, but with the current state of abstractions this is the best way to get to the system. It’s hard to overstate how different thinking in terms of QUBOs is for most scientists and developers. Plausibly benefit / formulate: This is not (yet) an exact science. We know our QPU is best at discrete optimization or sampling (I should note in a hybrid quantum/classical mode). The problem should be big enough that classical solvers run unacceptably long but not so big that, even with a decomposing solver, the QPU is contributing too little. And it should be valuable to your org, as this is quite a bit of work. Formulate the problem, usually as a QUBO but sometimes using higher-level abstractions. You might well have to try some problems more than once to get a good mapping. Those of you who want to bring your quantum physics expertise to bear can use lower-level interfaces. Performance does not come easily. You can do some things to tune a problem directly, and our tools are early, so your feedback or even development (since they’re open source) will help them co-evolve with apps.
• #17: Finally, when you might be thinking this seems like an awfully difficult path to pursue, let me end with a glimpse of some early proto-apps that point the way to using the machine effectively.
• #18: First is work we did with Volkswagen last year for CeBit, exploring the use of a D-Wave system to optimize traffic flow, which was valuable for VW in the context of autonomous vehicles.
• #19: They explicitly wanted to start with a real-world problem. The open-source data describes the movement of taxis in Beijing, traveling between the city center and the airport. The goal was to choose routes for each taxi that minimized overall congestion.
• #20: The constratints were straightforward …
• #22: The next app is topical given the current political situation in the US, Max Henderson of QxBranch (the “x” is silent) used quantum machine learning to understand the 2016 presidential election better.
• #23: Everyone knows that Donald Trump won the electoral college, but you may have forgotten how completely wrong most of the predictions were, giving him only a miniscule chance of winning.
• #24: Max extended some earlier work with Steve Adachi of LMCO building deep neural nets to create a more robust model. One notable point is that states were correlated, not independent as almost everyone modeled them.
• #25: The resulting models were able to learn extra structure beyond what the conventional models were using, and those models gave Trump a much higher chance of winning
• #26: Lastly, in another unexpected market, media, and specifically choosing the ads displayed on smart phones. In practice this is a real-time application, with about 100ms to choose an ad. (Recruit did not run these real-time.)
• #27: They want to optimize “click through rate” or CTR but they also want to give less volatility than the current methods, and they also wanted to pace the ad spending over the whole period in question, not exhaust all the funds at the outset. They found that the D-Wave method gives about the same CTR, lower volatility, and better budget pacing. This is a place where D-Wave use enabled them to add constraints they had not previously incorporated.
• #30: I’ve talked about the type of QC D-Wave builds, how we see ourselves delivering differentiated performance, how you, if your org is computationally differentiated, could adopt QA, and what applications some early adopters have mapped to our systems.