If we are going to build Quantum Computers (and we definitely are going to build them a soon as possible), what kind of software will then need?
I admit that my math skills aren’t really up to groking the details of QC, but software and software tools I do understand.
There are several important QC projects already in progress by Google , IBM , Microsoft , and probably others. These companies even aspire to sell time on their QC, which means they have to have some way for people to actually use them, no?
So how do you program these marvels?
This month Frederic T. Chong, Diana Franklin, and Margaret Martonosi survey the challenges of Programming languages and compiler design for realistic quantum hardware .
They point out that QC is in a state similar to classical computing in the 19050s: hardware is rare and expensive, and every iota of performance counts. However, unlike ENIAC days, we have deep and broad “toolchains” with the concomitant abstractions and optimizing technology. The trick, then, is to work out the best ways to let humans specify programs, and compilers generate code for QC.
“To make quantum programming manageable and quantum systems practical, we must expose the appropriate set of low-level details to upper software layers. The trick is to pick the best ones, those that will allow programmers to express programs while producing software that gets the most computation out of physical machines.” (, p. 180)
This is what we spent several decades doing for classical computers, and then again for multicomputer systems, and along the way, for problem specific languages, such as logic design. With QC, it’s back to basics, except we have a whole lot of experience at this game now.
One interesting factor is that QC (at least today) is similar to both general purpose computing (i.e., the programmer describes an algorithm) and also resembles hardware definition languages (the programmer needs to specify strict resource constraints). This is, so far, done in a “quantum co-processor” model, and most systems support QASM assembler code (about which I know nothing at all).
(Note that these early systems run on conventional computers so they, by definition, cannot simulate or debug realistic quantum programs. Eventually, the compiler and debugger will need to run on a quantum machine.)
One of the interesting requirements is that the quantum physics of the computer must be enforced by the compiler. (This kind of physical constraint is true of classic computing tools as well, but we just don’t notice any more. For example, the compiler “knows” that time is discrete and runs forward, that registers have only one value at a time which does not change without external input. Etc.) In the case of QC, there is quantum weirdness that must be respected.
These physical details of the hardware are not yet “virtualizable” in the way that classical computing provides a simplified, abstract virtual machine. Perhaps that will come someday, which will be interesting to see, and also will be yet another significant contribution to human knowledge.
The Nature paper describes some mind-blowing challenges, such a Qubit “garbage collection”, and runtime checking that operations on a Qubit are kosher with respect to other Qubits that are entangled. Again, it is theoretically impossible to fully (or even close to fully) simulate the computation, so these optimizations are done through heuristics and run time checks.
The paper describes quantum programming languages that have been developed, both functional and imperative. The authors note that current languages do not support verification (e.g., specification of correctness conditions). In QC there is also a need for knobs to specify error tolerance and precision, at the level of each individual output!
Compiling quantum programs is a bit different. For one thing QC programs are not as general as classical programs, and it is often the practice to compile the reprogram separately for each input value. This means that the compiler knows a lot about the program path, and can, for instance, aggressively unroll loops. (This stuff is certainly a juicy problem for the compiler jocks out there!)
Other interesting tasks are managing run time compilation for certain operations, and managing the interactions between a classical computer controller and the quantum coprocessor. (This sounds pretty hairy to me.)
Finally, bugs. Bugs, bugs, bugs. Whole new categories of bugs!
“when a new computer is built and tested, it will have errors. How will we distinguish between hardware and software bugs?” (, p.186)
Bearing in mind that conventional computers cannot simulate quantum calculations in any meaningful sense, how do we detect bugs? I note that some of my favorite debugging techniques, such as single stepping and repeatedly running a program with slight variations will not be very useful or even possible on a QC. Heck, you can’t even copy a value or otherwise snoop on the execution. What’s a poor programmer to do, ma?
We are going to need new and probably weirdly magical debugging techniques.
This is an amazing and inspiring survey. It also makes my brain hurt. : – )
- Davide Castelvecchi, IBM’s quantum cloud computer goes commercial. Nature, 543:159, March 6 2017.
- Frederic T. Chong, Diana Franklin, and Margaret Martonosi, Programming languages and compiler design for realistic quantum hardware. Nature, 549 (7671):180-187, 09/14/print 2017. http://dx.doi.org/10.1038/nature23459
- Steve Dent, Microsoft’s new coding language is made for quantum computers. Engadget.September 28 2017, https://www.engadget.com/2017/09/26/microsoft-new-coding-language-is-made-for-quantum-computers/
- Masoud Mohseni, Peter Read, Hartmut Neven, Sergio Boixo, Vasil Denchev, Ryan Babbush, Austin Fowler, Vadim Smelyanskiy, and John Martinis, Commercialize quantum technologies in five years. Nature, 543:171–174, March 9 2017.