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:

  1. Introduction to the problem.
  2. Mathematical reformulation of the problem.
  3. Unoptimised implementation of the solution.
  4. How to optimise a quantum circuit? (this post)
  5. Optimising multi-controlled X gates.
  6. 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("", "w") as f:

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 | gprof2dot | dot -Tsvg -Gbgcolor="#00000000" -o ibmq_challenge_non_optimised.svg

The final SVG file obtained is reproduced here:

Profiling of the non-optimised solution. If you have hard time understanding the meaning of this graph, have a look at the [gprof2dot documentation]().
Profiling of the non-optimised solution. If you have hard time understanding the meaning of this graph, have a look at the gprof2dot documentation.
Note that the 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.
Adrien Suau
Adrien Suau
Entrepreneur in Quantum Computing

I am an entrepreneur in quantum computing. I also do business consulting, so feel free to reach out!