Some background: I'm currently running the same training algorithm with a classical neural network and a quantum circuit, respectively. The NN is implemented in Keras with a TensorFlow backend, the circuit is implemented in TFQ.

My circuit has only 4 qubits and 88 trainable parameters, and training is still at least a factor 10 slower than training a NN with two dense layers (10 units each) and 182 trainable parameters. (All hyperparameters are identical.) At this moderate circuit size I don't expect circuit training to be that much slower than training the classical NN.

Looking at the CPU usage, I see that TFQ uses all cores, but only to a fraction. My suspicion is that the circuit is too small to reach the threshold where multiprocessing makes sense, so this might be a source of the slowness. However, I can't seem to find a way to turn multiprocessing off.

Question: Is there a way to disable multiprocessing in TensorFlow Quantum?

  • $\begingroup$ My guess is that a lot of circuits are being executed in parallel although each circuit is not taking a lot of CPU resources. Might be related: github.com/tensorflow/quantum/issues/255 $\endgroup$
    – taper
    Jan 28, 2021 at 18:08

1 Answer 1


There is no way to disable multiprocessing in TensorFlow Quantum without also affecting TensorFlow. That being said, there are still some workarounds to your problem that might be worth trying. It might help to take a look at changing the inter and intra op parallelism in tensorflow . If you are finding that TFQ isn't making full use of multiprocessing you might want to turn down the intra op parallelism.

In the past when I've seen patterns like that in my code, a lot of times it had to do with other things like waiting for the tfq.convert_to_tensor function to finish running in between each epoch and the fast C++ portion of my model finished so quickly that it just looked like a little blip on all the cores. Another common hiccup I'd hit is accidentally gathering the contents of a tensor and doing something like printing it, in between "hot paths" in the model. A good way to make these kinds of problems more apparent is to temporarily crank up the number of qubits and then try to isolate the major stages of your training loop to find the bottleneck. My personal guess in your case is that pure python code like tfq.convert_to_tensor is being called in between the training epochs and the epochs themselves are still very fast.

There was no code provided so I can't give any more help than just general advice, but if you are absolutely convinced it is not any of the things I mentioned above then you could use TensorBoard (tutorial with TFQ here) to profile the underlying model code and see where things might be slowing down.

  • $\begingroup$ Are there other pure python suspects like tfq.convert_to_tensor ? $\endgroup$ Jan 29, 2021 at 4:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.