1
$\begingroup$

I am performing many repetitions of a memory experiment in a stabilizer code using sinter to take many samples of different stim circuits. I am following the example in sinter's README file on how to perform this in the linux command line, namely by creating stim circuits in a directory ('circuits') and then running:

sinter collect \
    --processes 4 \
    --circuits circuits/*.stim \
    --metadata_func "sinter.comma_separated_key_values(path)" \
    --decoders pymatching \
    --max_shots 1_000_000 \
    --max_errors 1000 \
    --save_resume_filepath stats.csv

I would like to run this for a very long time (using a very large number for --max_shots) but be able to dedicate a certain number of processor cores to different groupings of circuits. I tried creating groups of circuits in different directories (e.g. circuits1 & circuits2), then creating a linux screen for each group and running the above command but it did not seem to be working at full capacity. I say this because on the 64 core machine I have access to if I run sinter collect on one screen with --processes 32 while working on circuits1, my computer's resource estimator shows that I am using about 50% of the CPU. If I then create another screen and run sinter collect on that, also with --processes 32, my resource estimator still shows that I am only using about 50% of my CPU. Both of the stats.csv files are updating, so they are both working, but if I am only using 50% of the CPU it seems like they could be working faster. Additionally, if I run sinter collect on one screen with --processes 64 it shows 100% usage of the CPU, and if I try to start another screen with --processes 64 I get an error.

$\endgroup$

1 Answer 1

1
$\begingroup$

Try your two-screen approach again, but after running pip install --upgrade sinter~=1.12.dev pymatching~=2.1.

The issue is probably that you were bottlenecking on disk usage. You were probably also only getting 50% utilization under normal usage of sinter. On my 96 core machine, sinter v1.11 is very sporadic on what utilization it gets, and it's often less than 50%, but ~=1.12.dev consistently has all the CPUs at 100% according to top.

The disk bottleneck was fixed in 1.12.dev by internally introducing the notion of a sinter.CompiledDecoder to amortize the cost of configuring decoders. In v1.11 the cost of configuring a decoder was amortized by working on shots in huge batches. Batches so large that they required storage to disk, which made the disk a bottleneck on high core machines.

$\endgroup$
4
  • $\begingroup$ Hi Craig, thanks very much for your answer. I installed sinter 1.12.dev and pymatching 2.1 but unfortunately I still have the same issue. Maybe it is something to do with the computer I am running it on? I'm on a node of a computing cluster running RHEL 7.9 which has 2 processors each with 32 cores $\endgroup$
    – drumadoir
    Commented May 2, 2023 at 3:50
  • 1
    $\begingroup$ @drumador hmmmm... Okay, now I think it's because sinter always sets cpu affinity, and always starts from 0. So both are trying to pin to the same cores. I'll have to add an argument to control that. $\endgroup$ Commented May 2, 2023 at 5:06
  • $\begingroup$ Sounds good - thanks! $\endgroup$
    – drumadoir
    Commented May 2, 2023 at 6:02
  • $\begingroup$ @drumadoir The issue is github.com/quantumlib/Stim/issues/550 . I suspect you could do it if you wanted to, in order to get it done sooner rather than later. $\endgroup$ Commented May 2, 2023 at 18:07

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.