Add tensordot-based method to default.mixed device

[dwierichs]

Context:
The _apply_channel method of default.mixed devices uses qml.math.einsum.
For a device with n wires, einsum does not support applying operations that act on all n wires if n>7, see #3582.

Description of the Change:
This PR adds an _apply_channel_tensordot method to the device, which does not have the above problem.
In addition, preliminary benchmarks showed that the tensordot-based method is equally fast or faster for operations that act on more than a single qubit. Therefore, this PR not only switches the device to use the new tensordot-based method if an operation acts on more than 7 qubits, but already for all multi-qubit operations.

Benefits:
Support of many-qubit operations.
Performance upgrade for multi-qubit operations.

Possible Drawbacks:
A bit of code duplication/complexity. If this is a major drawback, it probably is best to even remove the old einsum-based method, as its performance gain compared to the new method is small even for single-qubit operations.

Related GitHub Issues:
#3582

[codecov]

Codecov Report

Merging #3584 (f45437c) into master (4603d2a) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #3584   +/-   ##
=======================================
  Coverage   99.80%   99.80%           
=======================================
  Files         331      331           
  Lines       29078    29102   +24     
=======================================
+ Hits        29021    29045   +24     
  Misses         57       57           

Impacted Files	Coverage Δ
pennylane/devices/default_mixed.py	100.00% <100.00%> (ø)
pennylane/ops/channel.py	100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[ankit27kh]

Hey @dwierichs, I tested this with my original use case, and the results match. Also, this is much faster. For a 10 qubit circuit, einsum implementation took ~120 seconds while tensordot implementation took ~1 second.

Note that the results do not match exactly and differ in 15th or higher digit after the decimal for probability value.

[dwierichs]

Hey @ankit27kh, that is great to hear!
Deviations on the 15th decimal place are very common, I'd say, as this is touching the representation precision of float64. As the order and number of floating point operations likely is changed by the patch, I'd be surprised if they would match to even higher precision, where the decimal places basically can be discarded anyways.

[rmoyard]

It looks great, nice boost 💯 I have a couple of questions though

[dwierichs]

I performed some more comparisons, and the performance of einsum vs tensordot depends heavily on the used interface. As the mixed simulator works for all interfaces, it's difficult to make a decision here. For JAX, for example, the einsum-based approach is fastest for almost all operations and device qubit numbers I considered (up to 6).

[dwierichs]

I ran a few additional timings (click image for proper size):

As we can see, there are massive speedups, but only for interface in [None, "autograd"] and unitary operations that have a single Kraus matrix, and significant slowdowns for other interfaces.
A boundary to decide for tensordot could be num_wires>3 and interface in [None, "autograd"] and len(kraus)>1, but that's already rather specific.

[rmoyard]

It looks all good, we just need one more test 👍

[rmoyard]

Some issues with pylint in the default mixed tests, after that it will be good to be merged 👍 @dwierichs

[rmoyard]

Thanks @dwierichs It looks good to me 💯

[albi3ro]

Thanks!