[Design] Improve proto wire size for serialized circuits
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Stale
- Domain
- performance
Research direction
Start by reviewing the serialization changes from #590, then inspect op_serializer.py, program.proto, and the related Python and C++ serialization code. Profile serialization and deserialization for small simulations, define the revised proto design and its wire-size and timing goals, and implement the changes across both languages.
Written by the indexing model from the issue text.
Description
Thanks to #590 we can now roll our own proto structures + serialization code. We should do some work to try and make our program.proto wire size and serialization code (python and C++) as fast as possible. Anecdotally I can say that in smaller simulation workloads ( < 10 qubits ) The lions share of the time in C++ is actually spent deserializing, this shouldn't be the case.
Some good steps for this project would be to:
-
Slim down the code in
op_serializer.pyand other modules as much as possible so that we have the bare minimum needed for our functionality. i.e. we don't allow boolean types in our serialization. -
Draft a new proto design spec for
program.protowith an eye for fast serialization time and small wire size. -
Gradually implement that new spec which would require steady changes in both python and C++ code.
- Dominant language
- Python
- Stars
- 2.2k
- Forks
- 674
- Avg merge
- 1d 14h
- Merged PRs (30d)
- 5
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from tensorflow/quantum
-
area/c++ area/core kind/bug-report
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
tensorflow/quantum#1140 ·
Maintainers usually reply within 1 day
-
Avoid hard-coding "quantum" in `scripts/` scriptsPossibly taken @openbotgit claimed this 23 days ago. Openarea/devops help wanted no QC knowledge needed priority/before-0.7.7
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
tensorflow/quantum#1082 · 2 comments · 1 reaction ·
Maintainers usually reply within 1 day
-
area/c++ area/core kind/bug-report
Difficulty 3/5 1-2 days Newbie friendliness 74/100
tensorflow/quantum#1141 ·
Maintainers usually reply within 1 day
-
Bug (likely typo) in `core/serialize/serializer_test.py`Possibly taken @mhucka claimed this 15 days ago. Openarea/serialization area/tests
tensorflow/quantum#1129 · 1 assignee ·
Maintainers usually reply within 1 day
-
Support Keras 3May be free again @rosspeili claimed this 118 days ago, and no pull request is open. Openarea/keras help wanted skill-level/intermediate
tensorflow/quantum#1090 · 5 comments · 1 assignee ·
Maintainers usually reply within 1 day
All issues in tensorflow/quantum
Similar issues
-
release
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
MichaelYcJo/SpecSeal#1535 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
valentinfrlch/ha-llmvision#769 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 75/100
daniel-ospina/tortoise#11937 · 1 comment ·
Maintainers usually reply within 1 day
-
good first issue help wanted python up-for-grabs
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
andrewsiah/agentswarm-data-tasks#238 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
cadence-workflow/cadence-ai-samples#175 ·
Maintainers usually reply within 1 day