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.

Sign up for GitHub

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

Jump to bottom

Investigate performance at 72-150 qubits #565

Open
stylewarning opened this issue Jan 25, 2020 · 0 comments
Open

Investigate performance at 72-150 qubits #565

stylewarning opened this issue Jan 25, 2020 · 0 comments
Labels
perf Performance (time or memory) related matters. tech-debt Technical debt because of incomplete, lazy, shortsighted, etc. software engineering.

Comments

@stylewarning
Copy link
Member

It is known that quilc hasn't been particularly optimized for performance. @notmgsk did some significant algorithmic work to improve things, and others have done things here and there. However, the performance curves look quadratic against qubit count.

This is a general issue to start investigating performance, determining what's slow, and start creating tickets to speed individual elements up.
@stylewarning stylewarning added the tech-debt Technical debt because of incomplete, lazy, shortsighted, etc. software engineering. label Jan 25, 2020
@stylewarning stylewarning added the perf Performance (time or memory) related matters. label Jan 30, 2020
@stylewarning stylewarning assigned ghost Jul 15, 2021
@ghost ghost mentioned this issue Sep 24, 2021
Merged
stylewarning pushed a commit that referenced this issue Oct 21, 2021
@stylewarning
add cl-quil-benchmarking system quilc-perf for perf. benchmarking
93b3ba3 
This is part of issue "Investigate performance at 72-150 qubits #565".

new modules:

  benchmarking/quilc-perf.lisp - primarily exports benchmark-nq
    function to get timings as nQ increases for various chip and
    program types. This also introduces a "chip preparation" step
    before running any benchmarks. This removes any overhead from
    running the first compile on a chip out of the first benchmark
    run. Currently, there is significant but not tremendous amount of
    initial overhead, but a PR under consideration might add
    significant additional preparation overhead, and these should not
    be be charged to the first run.

  benchmarking/quilc-mon-prof.lisp - builds on quilc-perf.lisp and is
    for monitoring and profiling, as opposed to simple benchmarks, and
    is a WIP of sorts in that, while it's been useful to run for
    probing and experimenting in a REPL, we ;; so far lack really good
    theory of operation and associated modes of ;; running. We hope
    with time to get there. Also, note that some of this is SBCL-only.

Makefile - add targets to run benchmark-nq a couple of ways: `make
  benchmark-nq` calls benchmark-nq one time, and `make
  benchmark-nq-2x` calls it twice. The idea is to capture the
  sometimes significant jump in performance observed between a first
  and second run within the same Lisp environment, due to the effects
  of "warming", caching, and the like.

cl-quil-benchmarking.asd - add new module quilc-perf and depend on 3
  additional systems: metering, qvm-app, sb-sprof
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
perf Performance (time or memory) related matters. tech-debt Technical debt because of incomplete, lazy, shortsighted, etc. software engineering.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@stylewarning @rigettizach