Refactor our allocators#59
Open
drwells wants to merge 4 commits into
Open
Conversation
These thresholds are based on some logging I did which revealed, for these parameter choices and 400 time steps of the heart model: 1. 4214607 calls to allocate a 'small' buffer and 51098 actual allocations, consuming 1.5 GB 2. 5618 calls to allocate a 'large' buffer and 27 actual allocations, resulting in just 27 MB Here the small buffers are in powers of 2 and the large are allocated to their exact size. This prevents very large buffers from allocating a lot of unused memory which hangs around forever. The numbers vary a lot per-processor but we typically have about two order of magnitude more small allocations than large ones with these thresholds, and they tend to use more memory.
This is based on some profiling and prevents huge arrays from hanging around forever.
Member
Author
|
This isn't a high-priority item, but there's something wrong about how I implemented the build system - we shouldn't merge until that's fixed. Alternatively we can ask codex to generate a CMake build system for us instead. |
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I wrote most of this a couple of months ago - I wrapped it up so I could do some more local profiling. The primary change is that very large buffers are now allocated to their correct size (not nearest power of 2) and stored in a separate buffer (see a113051 for measured values). That prevents allocating very large arrays which have a lot of unused space (due to the power of 2 strategy) while keeping small allocations the same. We also periodically deallocate arrays which have not been used in awhile.
The main result of this is that we have about the same number of total allocations (i.e., we still cache nearly everything) and the total heap memory usage is reduced by about 25% (as measured with heaptrack on two processors).
Another minor change is refactoring so that all Array types use the same buffer pool which should further reduce the total amount of memory used.