-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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.
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
Avoid ExtraInstructionAttributes
allocation on unit="dt"
#13078
Conversation
The default value for `Instruction.unit` is `"dt"`. Previously, the `OperationFromPython` extraction logic would only suppress allocation of the extra instruction attributes if all the contained fields were `None`, but `None` is not actually a valid value of `Instruction.unit` (which must be a string). This meant that `OperationFromPython` would always allocate and store extra attributes, even for the default cases. This did not affect standard gates appended using their corresponding `QuantumCircuit` methods (since no Python-space extraction is performed in that case), but did affect standard calls to `append`, or anything else that entered from Python space. This drastically reduces the memory usage of circuits built by `append`-like methods. Ignoring the inefficiency factor of the heap-allocation implementation, this saves 66 bytes plus small-allocation overhead for 2-byte heap allocations (another 14 bytes on macOS, but will vary depending on the allocator) per standard instruction, which is on the order of 40% memory-usage reduction.
One or more of the following people are relevant to this code:
|
Pull Request Test Coverage Report for Build 10680563760Details
💛 - Coveralls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, this is a straightforward improvement and good to see the memory overhead reductions in practice.
} | ||
|
||
/// Get the Python-space default value for the `unit` field. | ||
pub fn default_unit(py: Python) -> &Bound<PyString> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like I would put an #[inline]
on this since the compiler is less likely to inline a public function. But it doesn't really matter in practice, especially since this is the python path so that won't help anything.
…13078) The default value for `Instruction.unit` is `"dt"`. Previously, the `OperationFromPython` extraction logic would only suppress allocation of the extra instruction attributes if all the contained fields were `None`, but `None` is not actually a valid value of `Instruction.unit` (which must be a string). This meant that `OperationFromPython` would always allocate and store extra attributes, even for the default cases. This did not affect standard gates appended using their corresponding `QuantumCircuit` methods (since no Python-space extraction is performed in that case), but did affect standard calls to `append`, or anything else that entered from Python space. This drastically reduces the memory usage of circuits built by `append`-like methods. Ignoring the inefficiency factor of the heap-allocation implementation, this saves 66 bytes plus small-allocation overhead for 2-byte heap allocations (another 14 bytes on macOS, but will vary depending on the allocator) per standard instruction, which is on the order of 40% memory-usage reduction.
Summary
The default value for
Instruction.unit
is"dt"
. Previously, theOperationFromPython
extraction logic would only suppress allocation of the extra instruction attributes if all the contained fields wereNone
, butNone
is not actually a valid value ofInstruction.unit
(which must be a string). This meant thatOperationFromPython
would always allocate and store extra attributes, even for the default cases. This did not affect standard gates appended using their correspondingQuantumCircuit
methods (since no Python-space extraction is performed in that case), but did affect standard calls toappend
, or anything else that entered from Python space.This drastically reduces the memory usage of circuits built by
append
-like methods. Ignoring the inefficiency factor of the heap-allocation implementation, this saves 66 bytes plus small-allocation overhead for 2-byte heap allocations (another 14 bytes on macOS, but will vary depending on the allocator) per standard instruction, which is on the order of 40% memory-usage reduction.Details and comments
I'm using the same sort of microbenchmarking script I've been using since #12730, but now modified to use
append
instead of the special methods onQuantumCircuit
:The memory usage of
main_append
for the parent of this PR is approximately 2.3GB on both macOS, and Linux with glibc, whereas with the PR it drops to 1.35GB on macOS and 1.06GB on Linux/glibc. I suspect there's something additional going on in the macOS one, because while the Linux/glibc one drops to match the memory usage ofmain_methods
(as expected), macOS remains 300MB higher. It might have been different Python versions - I used 3.10 on macOS and 3.12 on Linux.