Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shot branching optimization for multi-shots simulations #1596

Closed
wants to merge 25 commits into from

Conversation

doichanj
Copy link
Collaborator

@doichanj doichanj commented Sep 13, 2022

Summary

This PR is implementation of optimization for multi-shots simulations with operations with randomness (measure, reset, initialize, kraus or noise sampling)

Details and comments

Starting from 1 state, the simulation branches state into some states caused by randomness of the operation. Simulation time will be decreased when the number of the final branched states is smaller than number of shots.
To implement this optimization, I moved qreg and creg into Register class and most of the functions of State class takes reference to the Register so that each function can handle Register class independently to manage multiple branched states.

I implemented run_shots function in State class that simulates multiple shots with or without shot branching optimization and also batched execution for GPU.

Here is performance measurements of shot branching using QFT circuits with 1% of Kraus noise (1000 shots)
image
Since there are so many branches in noise simulation, the effect of this implementation is limited. Smaller noise ratio, larger qubits and larger number of shots will improve performance for this test case.
I think shot branching has more advantage in simulating circuits with intermediate measurements. (smaller number of branches)

Copy link
Collaborator

@hhorii hhorii left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just left reasons of some compilation errors.

break;
case Gates::rzx:
BaseState::qregs_[iChunk].apply_rotation(op.qubits, QV::Rotation::zx, std::real(op.params[0]));
qreg.apply_rotation(op.qubits, QV::Rotation::zx, std::real(op.params[0]));
break;
case Gates::ecr:
BaseState::qregs_[iChunk].apply_matrix(op.qubits, Linalg::VMatrix::ECR);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

iChunk is not defined.

break;
case Gates::rzx:
apply_matrix(op.qubits, Linalg::VMatrix::rzx(op.params[0]));
apply_matrix(state, op.qubits, Linalg::VMatrix::rzx(op.params[0]));
break;
case Gates::ecr:
apply_matrix(op.qubits, Linalg::VMatrix::ECR);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no matching member function for call to 'apply_matrix'

@@ -632,26 +509,27 @@ bool StateChunk<state_t>::allocate_qregs(uint_t num_chunks)
//allocate qregs
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

qregs_ is not defined.

@hhorii
Copy link
Collaborator

hhorii commented Jan 24, 2023

Current interface of State looks very complex:

template <class statevec_t = QV::QubitVector<double>>
class State : public QuantumState::StateChunk<statevec_t> {

  void apply_op(QuantumState::RegistersBase& state, 
                const Operations::Op &op,
                ExperimentResult &result,
                RngEngine& rng,
                bool final_op = false) override;

Though State has qreg of state_t and StateChunk has qregs_ and std::vector<state_t>, state of QuantumState::RegistersBase is used here. Registers of QuantumState::RegistersBase also have qregs_
of std::vector<state_t>. Also, in methods, implementations are different based on execution strategies (batch execution, shot-branching, and etc). Now Aer has many strategies for simulation such as combination of sampling/non-sampling, shot-branching+sampling, chunk (GPU and MPI), and batch-execution. I think we need another layer between Controller and State and manage execution mode and then we should keep simplicity of State as a common interface to qubit vector, mps, stabilizer and so on.

For 0.12, I think we do not need such refactoring, but for 0.13, we need refactoring.

@hhorii hhorii modified the milestones: Aer 0.12.0, Aer 0.13.0 Feb 7, 2023
@hhorii
Copy link
Collaborator

hhorii commented Mar 10, 2023

@doichanj will create a new shot-branch implementation with some refactoring work in State classes.

@hhorii hhorii closed this Mar 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants