Skip to main content
deleted 31 characters in body
Source Link
Adam Zalcman
  • 24.8k
  • 3
  • 38
  • 92

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.

Hope this helps,

Michael

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.

Hope this helps,

Michael

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.

Source Link
Michael
  • 393
  • 1
  • 5

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.

Hope this helps,

Michael