-
-
Notifications
You must be signed in to change notification settings - Fork 87
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
Change formula for chunking of files in combine
#642
Conversation
Memory profiling of
|
Commit | Description |
---|---|
38d14d2 | This PR, BEFORE adding memory factor (effectively current master) |
5ec598c | PR #632 -- use numba JIT to speed up median sigma clipping |
e73b93e | PR #630 -- Reduce number of open files and del some variables |
df233f3 | This PR, AFTER adding memory factor but BEFORE additional factor of 1.5 |
a73e72f | This PR, AFTER modification of memory factor by additional factor of 1.5 |
a73e72f | As above, but memory limit of 2GB |
TL;DR results (red vertical line is memory limit)
Before this PR | After this PR |
---|---|
Profiling of 38d14d2; notebook link
Commit on this PR, before adding memory factor (effectively current master)
Summary: Combination with average or sum routinely use 2x memory limit; median uses 3x
Runs with no sigma clipping
Runs with sigma clipping -- WRONG (no sigma clipping was done)
Profiling of 5ec598c; notebook link
PR #632 -- use numba JIT to speed up median sigma clipping
Summary: Roughly the same as case above, but somewhat higher memory use in median
Runs with no sigma clipping
Runs with sigma clipping -- WRONG (no sigma clipping was done)
Profiling of e73b93e; notebook link
PR #630 -- Reduce number of open files and del
some variables
Summary: Roughly the same as first case above, but memory use more frequently drops back to near zero
Runs with no sigma clipping
Runs with sigma clipping -- WRONG (no sigma clipping was done)
Profiling of df233f3; notebook link
This PR, AFTER adding memory factor but BEFORE additional factor of 1.5
Summary: Memory use same for all combine methods, but ~50% higher than limit
Runs with no sigma clipping
Runs with sigma clipping -- WRONG (no sigma clipping was done)
Profiling of a73e72f; notebook link
This PR, AFTER modification of memory factor by additional factor of 1.5
Summary: All methods use about same memory; while limit is exceeded, it is not by much or for long
Runs with no sigma clipping
Runs with sigma clipping -- WRONG (no sigma clipping was done)
Profiling of a73e72f, memory limit of 2GB; notebook link
Same as previous case, higher memory limit
Summary: All methods use about same memory; while limit is exceeded, it is not by much or for long
Runs with no sigma clipping
Runs with sigma clipping -- WRONG (no sigma clipping was done)
This is ready for a look (I think the tests will pass) |
Thanks for the profilings. However it seems a bit odd at least for the numba solution I expected significantly lower memory usage (maybe the intermediate boolean arrays aren't a problem after all...) and at least a bit of performance improvement (that I cannot see from the timeline in your measurements). However I probably won't have time to look at this (and the other PRs) today or tomorrow. |
I'd be hesitant to draw any performance profiling conclusions from this (I don't know how the memory profiling itself affects performance) but I was a little surprised too. Can try re-running it this weekend.... |
Hmmm, may be time to update some of the test matrix entries...failures are because of PathLib vs string for name of directory issues. |
@mwcraig Just a thought but could you separate the different parts of the PR into separate PRs? There are essentially 3 things here: the refactor of the "size estimate" (which is very good and straightforward), the "fudge factor" (which I would prefer not to have), and the "memory testing" (which could be very useful but requires a more thorough review). That's by no means necessary it would make reviewing and discussing the different parts just a bit easier. |
For the |
Is it possible that it hasn't picked up the current state and some other installation? I just had a look at #632 and the performance difference should be immense enough to be clearly visible here as well (or I'm missing something obvious). |
Turns out my script to turn clipping on set all of the sigma clipping parameters but not A couple examples with sigma clipping are below; in them the difference in timing between the numba version and a non-numba version (current master) is clear. The memory use in both cases is about the same and (thankfully) not that different than in the original plots above. Memory profile, numba branch, sigma clipping onMemory profile, current master (d1b67f0), sigma clipping on |
I'd rather not...I think the memory test and change in memory formula should be together because the parameters to use in the test depend on what we expect the memory usage to be. |
I ran the profile below today to try to get a better sense of why the memory limit calculated in the combine function underestimates actual memory use by so much. The profile below was run with parameters set so that would be no breaking into smaller chunks. I ran it on the tip of the branch for the open files PR because that PR eliminated some potential memory overuse. I used The first think that jumps out is that It looks like in the average combine case, at least, and additional spike of 50% more memory happens when the actual combination happens (in this case via Not sure why that uses a temporary ~50%. Will post a profile of
|
The median profile confuses me. In the time-based profiles graphed above, median clearly peaks out at higher memory than average or sum. The profile below uses less memory (peak) than the profile of average above. 🙄
|
If |
ccdproc/tests/run_profile.ipynb
Outdated
"from matplotlib import pyplot as plt\n", | ||
"import numpy as np\n", | ||
"\n", | ||
"from run_for_memory_profile import run_with_limit, generate_fits_files\n", |
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.
Raise an obvious exception in case memory_profile
is not installed.
because apparently numpy 1.13 can be a little more memory-intensive than others
This PR fixes #638 by changing the formula for calculating the way the number of chunks is calculated in
combiner.combine
. While the change looks a bit arbitrary (adding "memory factor" of 2 or 3 depending on the combine method, and another factor of 1.5) it is best on memory profiling of several cases, described in the comment below. I believe the pattern of memory use bycombine
is consistent enough to justify the insertion of these factors.Two things remain to be done to complete this PR, I think:
Increase current default memory limit (?).Seems unnecessary, since it is currently at 16GB.Next up, profiling justification for these changes....