I am interested in looking into histogram distributions of decoder timing for different syndrome inputs (sourced from stim) into pymatching. Unfortunately, it seems the histograms I product are more a function of how my PC runs the simulations vs actual differences in how pymatching handles different syndrome inputs. As an example, I produced two overlaid timing histograms below to show what I am talking about.

enter image description here

Orange shows decoding times for different stim output syndromes, while blue shows the decoding times for decoding the same syndrome data over and over. Given the very close agreement, it seems that any data I get with how I am doing this tells me absolutely nothing about the syndrome input's effect on decoding times.

I am wondering if anyone knows why this is happening. Maybe a problem with my implementation? Does pymatching use some randomness in its decoding process? Maybe to select the first root to start an alternating tree. If so is it possible to define a seed? Maybe relying on python for such sensitive timing was doomed to fail from the start.

Here is the code used to generate the data above, changing the distance or error rate input changes the exact distribution, but the agreement is always quite good with rare exception. There is a chance of getting an syndrome set that is actually more difficult to decode, and if that is the first shot of the sampler then the blue distribution can be shifted to higher times.

# Inputs
distance = 11
reps = 11
shots = 1000000
noise = 1e-3

# Define circuit and matching graph
circuit = stim.Circuit.generated(
error_model = circuit.detector_error_model(decompose_errors=True)
match = pm.Matching.from_detector_error_model(error_model)

# Sample results
sampler = circuit.compile_detector_sampler()
syndromes, observables = sampler.sample(shots, separate_observables=True)
int_syndromes = np.array(syndromes).astype(dtype='uint8')

# Decoding number of shots
times_same_data, times_different_data = [], []
for s in range(shots):
    same_start = time.time()
    same_end = time.time()
    times_same_data.append(same_end - same_start)

    different_start = time.time()
    different_end = time.time()
    times_different_data.append(different_end - different_start)

1 Answer 1


I couldn't reproduce this. Here's what I get for most of the output from the above (replacing time.time() with time.perf_counter())

Runtime Histogram

There are a few outliers probably down to whatever else is running at the time

Zoomed out runtimes

  • $\begingroup$ Thanks for taking a look Chris! I tried the same timing strategy with 'perf_counter()', and there is still a similar type of variance (just at lower orders of magnitude) even if I don't run any code between recording start and end times. Likely something wrong with my specific machine unfortunately. Your answer helped me get there though. $\endgroup$
    – Ian
    Commented Jan 13, 2023 at 9:44
  • $\begingroup$ Out of curiosity what type of machine/environment did you run this on? $\endgroup$
    – Ian
    Commented Jan 13, 2023 at 14:51
  • 1
    $\begingroup$ python 3.9 on an m1 macbook. $\endgroup$
    – ChrisD
    Commented Jan 15, 2023 at 1:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.