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.

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

Reduce memory usage #24

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open

Reduce memory usage #24

wants to merge 6 commits into from

Conversation

mkbosmans
Copy link

@mkbosmans mkbosmans commented Nov 29, 2022

This adds a performance test script and some memory optimizations for ipfn_np.

On my test system 10 iterations for a 12,000x12,000 matrix go from 36 seconds to 21 s. The peak memory usage goes down from 6.2 GB to 1.8 GB.

It is split in multiple commits, so that each individual change is easy to review.
Changes are on top of the vortechbv/ipfn:cleanup branch, so it probably makes sense to merge #23 first.

mkbosmans and others added 6 commits November 28, 2022 21:06
User-visible strings should be quoted with " and ' is for internal strings.
The max_itr is now more explicit and the convergence criteria are only
checked in one place instead of in the while condition and after the loop.

The loop now actually stops after doing max_itr iterations, where previously
it would do iterations numbered 0 to max_itr, i.e. one iteration too many.
This will construct a large matrix that converges slowly.
The matrix is 12000x12000 single precision numbers, in total 576 MB.
The self.original and self.aggregates are never modified but kept the
same as the original user input.  The `m` and `aggregates` variables are
a copy of the user input and may be modified during the iterations.

The `iteration` method is responsible for converting the user input to a
numpy array of floats.  The `ipfn_np` function only checks whether that
condition holds but does no conversion.  This allows the `ipfn_np` to be
used directly for user that want absolute minimum memory usage without
any extra copy of the input array.

Instead of always converting to float64, the input arrays are now only
checked if they are of floating point type.  This means that a single
precision float32 array will be kept that way, allowing for a smaller
memory footprint, if the problem allows the lower precision.
…matrices

This save some memory in case of more than two steps.
Since the previous commit we don't need an integer loop index `inc` anymore,
so simply using zip over `aggregates` and `dimensions` is more clear.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant