IBM Quantum Challenge 2020 - Part 4
This post is part of a serie of posts on my experience with the IBM Quantum Challenge 2020.
The serie is organised as follow:
- Introduction to the problem.
- Mathematical reformulation of the problem.
- Unoptimised implementation of the solution.
- How to optimise a quantum circuit? (this post)
- Optimising multi-controlled
X
gates. - Optimising the
QRAM
(Quantum Random Access Memory).
This post shows how to use a tool I developped a few months ago to benchmark a quantum circuit. It is not directly related to the IBM Quantum Challenge but helps in understanding my thought process in the next sections that deal with actual code optimisation.
How to optimise correctly
Before even thinking about modifying code to optimise, a crucial thing should be clear in your head:
Sadly, the system I use to write this post (wowchemy, amazing work) does not allow me to emphasize this even more: BENCHMARK, BENCHMARK and BENCHMARK.
Without benchmark, you cannot know for sure what part of your implementation is slow. You may guess, and you may guess right, but you will not know for sure until you implemented the optimisation and saw the results. Benchmarking allows you to have a certainty about the problematic parts of your code.
Now that you know that you need to benchmark, another issue arise: how to benchmark a quantum circuit?
The issue I just raised, “how to benchmark a quantum circuit?”, is actually the representation of a larger issue in the quantum computing community which is the lack of tooling.
Quantum software implementers have access to amazing frameworks to write down quantum circuits and even execute them on the cloud, but good tools to analyse the generated quantum circuits or help in debugging them are still lacking.
qprof
, the quantum profiler
It turns out I already faced this problem in the past with an
even bigger and complex quantum circuit: my implementation of a
quantum wave equation solver. In order to
benchmark correctly this implementation I made a tool called
qprof
.
You can have a look at the project presentation page of
qprof. In a nutshell,
the tool aims at being generic quantum profiler, capable of
profiling quantum circuits written with several different
frameworks (Qiskit and
myQLM for example) and able to output
the results in different formats (only gprof
-compatible at the
time being).
The qprof
published in PyPi is slightly outdated. This is
something I need to fix eventually, but for the moment I
recommand you to install qprof
from source. See the section
“Installation -> For developers”.
Moreover, the documentation / posts about qprof
might be a
little bit outdated.
If you have any question on the tool or want to participate to the development, feel free to contact me.
Using qprof
on the Quantum Challenge code
As a reference, here is the link of the non-optimised version we obtained at the end of the last blog post: link to Gist.
Benchmarking with qprof
is actually very simple. Once
installed, you simply have to call the profile
function with
the appropriate arguments.
from qprof import profile
circuit = None # Generate your quantum circuit here.
# Dictionnary that maps gate names (in upper-case) to their cost.
# If a gate is missing, an exception will be thrown by the profile
# function to let you know.
gate_times = {"U3": 1, "U2": 1, "CX": 10, "MEASURE": 0}
text_result = profile(circuit, gate_times, "gprof")
with open("profile_result.prof", "w") as f:
f.write(text_result)
In order to have exploitable results, I also added names to the
QuantumCircuit
instances created.
The full profiling code is available in this Gist. With the help of the excellent gprof2dot and dot tools we can draw the profiling results using the command below.
cat profile_result.prof | gprof2dot | dot -Tsvg -Gbgcolor="#00000000" -o ibmq_challenge_non_optimised.svg
The final SVG file obtained is reproduced here:
gprof2dot
tool prune nodes (i.e. routines or
gates) that account for less than 0.5% of the total execution
time and edges (i.e. routine calls) that represent less than
0.1% of the total execution time.
This is why some of the percentages do not sum to what they
should.