Simulating the behavior of a quantum computer on a classical computer complements QC theory in several important ways:
- Theoretical analyses of physical systems often contain approximations for which error bounds are unknown or hard to calculate accurately. A numerical simulation can avoid such approximations.
- Computer programs help us to spot mistakes/omissions in theoretical proofs, algorithms and subtly incorrect preconceptions.
- Computer programs help us to visualize the implications of theory and to generate specific examples of it.
In addition, QC simulators are useful for developing and debugging QC algorithms of all types including: QC programming languages, quantum error correction algorithms, etc. In addition, QC simulators can be used to study how QC algorithms degrade with noise.
Numerous QC simulators that can simulate a small number (<=16 qubits) have been written, and you can find links to them at quantiki. Few of those take advantage of parallel computing though. This blog post is about those that do.
Two recent efforts to simulate QCs using parallel computers are
- D-wave’s AQUA@home The goal of AQUA (Adiabatic QUantum Algorithms) is to simulate the performance of superconducting adiabatic quantum computers. D-wave has a very nice webpage here explaining their setup. Their software was written by Peter Young (UCSC), Neil Dickson (D-Wave), Firas Hamze (D-Wave), and Kamran Karimi (D-Wave), et al.
- JUGENE QC simulator JUGENE is a supercomputer located in the town of Jülich, Germany. This excellent paper describes JUGENE’s 42 qubit QC simulator written by Hans de Raedt, his son Koen, Kristel Michielsen, et al. You may have already heard about it from this recent press release.
There are two main paths to massively parallel (a.k.a. high performance) computing (i.e., computing that achieves ~ e15 FLOPS). The poor man’s way and the rich man’s way.
Poor people like D-wave set up a central server that uses the Internet to send parcels of work to, and receive results from the PCs of volunteers who allow their PCs to be used during idle times. The central server also compiles all the results. To choreograph this intricate dance of information exchange, the central server and volunteer PCs use open-source software from Berkeley Univ., called BOINC. BOINC is used by many famous research projects besides aqua@home; for instance, SETTI@home, Folding@home, etc.
Rich people like the Julich group use a “big iron” supercomputer such as JUGENE. Here are some stats for that puppy:
4th in the top500 (Nov2009) biannual list (1st in Europe)
peak speed: ~e15 FLOPS
memory: 1.44e14 bytes
storage: 6.0e15 bytes
power consumption: 2-3e6 Watts for entire installation, 0.35e9 FLOPS/Watt
The Programmer’s Perspective: to write software that runs on a parallel computer, one uses special software libraries for “message passing”. A task may either share all its memory with other tasks, or none of it, or just part of it (a hybrid). In situations where memory is shared, one can use libraries such as CUDA (as in barracuda) and OpenMP. These are nicely described here and here by a very hungry game-coder named Mark Pope. In situations where memory is not shared, one can use a library called MPI. (For a quick introduction to MPI, see, for example, this) The code of aqua@home uses mainly CUDA, whereas the code of JUGENE’s QC simulator uses mainly MPI.
Recall that 1 complex number = 2 double precision reals = 16 bytes = 16*8 bits, and that n qubits are described by 2^n complex numbers. Hence
|qubits||number of complex numbers||bytes|
This explains why the JUGENE simulator is limited to 42 qubits. The reason is not that 42 is the Answer to the Ultimate Question of Life, but that JUGENE’s memory is about e14 bytes.