Hi @gojiita_ku,
No worries!
It seems, that in this specific case the following could be adjusted:
@qml.qnode(dev, interface="torch",diff_method='adjoint',mutable=False).
I.e., we’d like to have diff_method='adjoint' be passed to qml.qnode, instead of method='adjoint'.
If we’re not passing diff_method='adjoint', then the unknown keyword is ignored and we’re using the parameter-shift rule with the Torch interface.
Using the adjoint method resulted in a runtime of about ~110 seconds for me locally.
It seems, that in this specific case the following could be adjusted:
@qml.qnode(dev, interface="torch",diff_method='adjoint',mutable=False) .
I.e., we’d like to have diff_method='adjoint' be passed to qml.qnode , instead of method='adjoint' .
If we’re not passing diff_method='adjoint' , then the unknown keyword is ignored and we’re using the parameter-shift rule with the Torch interface.
Using the adjoint method resulted in a runtime of about ~110 seconds for me locally.
Hi @antalszava,
Thanks so much for pointing out the error I made! Yes, after replacing method='adjoint' with diff_method='adjoint', the new code also resulted in a runtime of about ~ 120 seconds in my local environment! This is an obvious speedup!
However, compared to classical image segmentation models, the quantum part still takes much more time (270s vs 0.16s for batch size of 2 in my case). So may I ask two more questions below?
-
Is there any other method to further reduce the run time of this quantum version of convolution? For example, could we exploit vectorization for pennylane?
-
If we use device as default.qubit.tf, intall tensorflow with gpu support and rebuild the model using tensorflow, would this quantum convolution be executed on gpu?
Hi @gojiita_ku,
Your questions are welcome!
- I am looking into it and I will come back to you tomorrow.
- Yes you are right, you can use
default.qubit.tf with diff_method=backprop it supports classical back propagation on GPU.
1 Like
Hey @gojiita_ku,
For the first question, I spoke with my colleague @jmarrazola and unfortunately we do no think that there is a straightforward way of further further speeding up the execution of the present code. Indeed at the moment simulating quantum circuits is harder than implementing neural networks.
For vectorization techniques it would probably need to happen at the level of how the device operates, which would require changing most of the code base.
Feel free to ask any other questions!
Hi @Romain_Moyard,
Thanks so much for your reply! I’m asking this question because I would like to make this type of hybrid quantum-classical models leap out of the lab and be more practical in certain real-world scenarios (e.g. medical imaging). Personally, I find the biggest obstacle I am facing is how to optimize the computation time of quantum parts of the model. Anyway, thanks for all of your supports! I believe this issue can be resolved soon in the future with some new features of Pennylane. 
By the way, may I further confirm one thing? Even though default.qubit.tf supports back-propagation method like TensorFlow, the computation of quantum circuits is still not based on vectorization, right? I mean quantum circuits in this case are still executed sequentially in for loops.
Hi @gojiita_ku,
That’s right, devices in pennylane don’t perform a vectorized simulation of quantum circuits. Instead, the approach is to create a tape representing the circuit and subsequently apply each operation in the tape to an initial state vector. This follows essentially the same logic required to execute circuits on hardware.
Your suggestion of a fully-vectorized simulator is intriguing. In principle this should be possible, but would require a large change to how simulators are designed and built. It’s also not clear that the gain would be significant 
Let us know if there’s anything else we can do to help!
Best,
Juan Miguel
Hi @jmarrazola,
Thank you so much for confirming my doubts! I’ll let you know if I got more questions about Pennylane.
1 Like