Cirq Performance Improvement Roadmap Item

[tanujkhattar]

This is a high level roadmap item that captures key areas where we need to improve performance in Cirq to support writing and running larger circuits in Cirq. The four key areas of performance improvements to enable M3 experiments are:

• Circuit Construction: This was addressed as part of PR5332 and PR5898. Constructing a d25 surface code memory experiment circuit with 625 rounds now takes ~32ms. Further improving this number is always better but we believe this is fast enough to not be a blocking roadmap item.

• Parameter Resolution: Running circuits for calibrations often require repeatedly executing parameterized circuits with different parameter values. cirq.resolve_parameters is slow #6091 gives a good overview of why cirq.resolve_parameters is slow. We should make the necessary changes to address the concerns raised in the issue.

• Circuit Transformations: PR5957 adds performance benchmarks for common circuit transformation primitives in Cirq. We need to make the primitives more performant to bring down the circuit transformations runtime for the (1000 qubit, 100 moments) to run under 100ms.

• Circuit Serializations: The Json serialization was not designed to be compact or fast. Benchmarks for json serialization, added in PR5957, show that it takes O(seconds) to serialize a (1000 qubit, 100 moment) circuit containing one and two qubit gates. We want this number to be O(milliseconds). To make this happen, see whether:

  • We can improve the performance of serialization/deserialization using the existing json serialization data model.
  • If not, design a new serialization model with better performance scaling.

Running list of blocking issues which must be addressed to mark this item as completed

• Option to disable validation checks to boost performance for common workflows #5988
• cirq.resolve_parameters is slow #6091
• Improve Serialization performance in Cirq #6110
• Hardware inverse transformer faster #6173

[vtomole]

Will we ever write parts of Cirq in C++ for performance improvements? What are the pros and cons of doing this?

[pavoljuhas]

Will we ever write parts of Cirq in C++ for performance improvements? What are the pros and cons of doing this?

(per @dstrain115, cirq sync meeting) C++ use is not currently planned. It will necessitate building separate packages for Linux, Mac, Windows which have different C++ toolchains and build environments. In the future we might consider Rust rather than C++.

[harshthakkar01]

Hi, I would like to contribute to this task.

[navaro1]

I have some experience in improving performance of serialization, hence would like to help with Circuit Serializations point.

[tanujkhattar]

@navaro1 That's great, I've opened #6110 to track serialization performance improvements. Can you leave a comment on this issue so I can assign it to you? Thanks!

[skushnir123]

I can take this issue.

[tanujkhattar]

@skushnir123 Can you leave a comment on #6091 instead?

[rht]

In the future we might consider Rust rather than C++.

Related: There is RustQIP that leverages Rust's borrow checker to enforce the condition of the no-cloning theorem. A Rust backend of Cirq would be able to have this feature. But how would the Rust backend interface with qsim?

[tanujkhattar]

@pavoljuhas I think this issue can be closed. The only remaining task is to speed up json serialization and the linked open PR by Piotr does a good job. The only blocker at the time was that it introduces an additional dependency and we need to evaluate whether that's okay or not.

I'll go ahead and close this for now and we can track serialization improvements in #6110