Add experimental support of cuQuantum

[doichanj]

Summary

This is the experimental support for NVIDIA's cuQuantum Beta 2 (ver 0.1.0).

Details and comments

We can use cuStateVec APIs instead of Aer's GPU implementations by setting options at runtime (see CONTRIBUTING.md for details). cuStateVec is enabled when building with CUSTATEVEC_ROOT with the path to cuQuantum.
By using cuStateVec, we can speed up x2 for large qubits (larger than 22 qubits) but Aer's implementation is still faster for smaller qubits.

Since cuQuantum is beta version, there are some limitations:

• cuStateVec is not thread safe, multi-chunk parallelization (cache blocking) is done by single thread (slow)
• Multi-shots parallelization is disabled (single thread, slow)
• Multi-shots batched optimization is not support for cuStateVec

[chriseclectic]

I added On-hold until 0.10 release is out

[hhorii]

I think introducing a new namespace is necessary for AER::QV to identify chunk-based or not. For example, GateFuncBase sounds too general and it should be in AER::QV::CHUNK or something.

[hhorii]

@doichanj a release note is necessary.

[jakelishman]

This probably should also wait for Aer 0.11 - it's a big new feature, and patch releases are usually for bugfixes.

[hhorii]

Now I found that OpenMP does not work well in any devices. Let me investigate this phenomena is from only my configuration or common.

[hhorii]

if cuStateVec_enable=True is configured in AerSimulator.run(), parallel_state_update_ is not set. This will produce performance regression if application accidientaly sets cuStateVec_enable with device='CPU'.

[leofang]

Question: when enable_batch_multi_shots_=true would you create nShots copies of the statevector for parallelization? If so & IIUC, I think a proper "workaround" is to create multiple cuStateVec handles (or just retain and reuse a pool of handles at init time to reduce overhead) and use them in parallel.

IMHO though it's beyond a "workaround": even after we fix the thread safety issue, generally speaking it is still challenging for library handles to be shared by multiple host threads. For example, despite cuBLAS supports this usage pattern they explicitly recommend to not do so. Thus the handle pool approach is commonly seen in ML/DL frameworks.

[doichanj]

enable_batch_multi_shots_=true is not applicable for cuStateVec currently, because multiple state vectors are calculated in a single CUDA kernel and each state vector refers classical registers to handle branch operations, this is not implemented in cuStateVec.
Multiple cuStateVec handle is required when enable_batch_multi_shots_=false and shot level parallelization is required. In this case, state vectors are independently calculated using OpenMP threads. (Currently cuStateVec is not thread safe and we disable OpenMP parallelization)

[leofang]

Thanks for explanation @doichanj. I understand better now. So once we fix thread safety we can unblock you for the shot-level parallelization.

[hhorii]

@chriseclectic could you review this change? This is a hack to minimize changes of tests for tests of cuStateVec option. cuStateVec is an option only for device=GPU. Current annotator supported_methods() requires tests to take two argument method and device. Adding new option cuStateVec_enable to all the tests is not productive, I believe.

[hhorii]

I confirmed that no regressions will be happened with this PR.