[WIP] Improve performance of QubitVector::sample_measure

[merav-aharoni]

Summary

The performance of QubitVector::sample_measure can be improved.

Details and comments

This is the same improvement made in PR#808 for MPS.

1. Instead of iterating over the full vector of probabilities, we collect only the non-zero probabilities and store them in a vector of accumulated probabilities.
2. Since this vector is strictly increasing, we can search for the index of rnd using binary search rather than linear search.
   I think we should actually implement this algorithm once in the base class 'State' so that we don't duplicate the code.

[merav-aharoni]

[yaelbh]

The problem here is quite general: randomize an outcome of a multinomial distribution. Any known efficient algorithms that we can apply?

[yaelbh]

Maybe sort the array rnds. Then the binary search is not done over the entire domain every time.

[yaelbh]

Also no need for a binary search. The algorithm should look like this:

<sort rnds>
uint rnd_index = 0;
for (sample = 0; sample < END - 1; ++sample) {
  while (rnds[rnd_index] < probability(sample)) {
    <increase count of measurement result `sample`>
    ++rnd_index;
  }
}

Complexity is O(shots + 2^n)

[merav-aharoni]

@yaelbh , that's a nice idea, but I am not sure which algorithm will work better. The performance depends on the number of shots and on the size of the probabilities vector, so to be really optimal, we may have to implement several algorithms and choose between them based on the above parameters. I am not sure it is worth the extra complication in the code. I tried to avoid that and kept only 2 algorithms.
One more point to note - the size of the probabilities vector will be much smaller than 2^n in the average case, because I store only the non-zero probabilities.

[yaelbh]

@merav-aharoni But in order to store the non-zero probabilities you already make a pass on all 2^n possible results. So I don't see the need to keep several algorithms.

[merav-aharoni]

@yaelbh , so do you want to implement it? that way Hiroshi can include it in his benchmarking. Because I won't get to it this week.

[yaelbh]

@hhorii I'm going to open yet another pull request for sample measure. Will you be able to include it in your benchmarking?

[yaelbh]

See #836.

[hhorii]

Probably, this PR is effective for smal qubits.

[hhorii]

index_vec and acc_probvector will require the same size of this qubit vector in worst case.

[merav-aharoni]

In the worst case, you are correct. But in most cases, these vectors will be must smaller than the qubit vector.

[hhorii]

Iterating all the qubit with a thread is too heavy for large qubit. Maybe this is not efficient for 25 or more qubits.

[merav-aharoni]

In my experiments, I went up to 26 qubits, and the results are pretty consistent. These experiments are on random graphs. The original algorithm also passes over the entire statevector to get the probabilities, so it has the same problem. But at least in the new algorithm, this is done only once.
The algorithm may not be so efficient when the depth is large, because then the acc_probvector will grow. I can try to rerun the experiments with higher depths to see how efficient it is. But maybe the best benchmark will be to run on your benchmarks, that represent more realistic problems. What do you think?