Parallel concatenate #5926
Open
Parallel concatenate #5926
Conversation
This file contains 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
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #5926 +/- ##
==========================================
+ Coverage 89.77% 89.80% +0.03%
==========================================
Files 90 90
Lines 22984 23052 +68
Branches 5031 5042 +11
==========================================
+ Hits 20634 20702 +68
Misses 1619 1619
Partials 731 731 ☔ View full report in Codecov by Sentry. |
bouweandela
added
the
benchmark_this
⏱️ Performance Benchmark Report: 11b4199Performance shiftsFull benchmark resultsGenerated by GHA run |
trexfeathers
reviewed
Jun 5, 2024
lib/iris/_concatenate.py
Outdated
There was a problem hiding this comment.
Would it be possible to fall back on 'normal equality' when hash equality is False?
Sorry to add more work to this, but I've been having some offline conversations with @bjlittle and @pp-mo about equality in general and we're concerned about Iris' strictness. The changes here would make Iris more strict than it is already.
We are therefore keen to use hashing as a way to confirm equality quickly and efficiently, while still retaining the chance for more lenient comparisons such as:
- Allowing
NaN(example). - Potentially allowing for floating point differences in future (thanks to @larsbarring for insights).
If this would harm the performance gains you are looking for then we would be open to configurable behaviour in concatenate().
There was a problem hiding this comment.
Thanks for providing me with feedback! ✨
I've been having some offline conversations with @bjlittle and @pp-mo about equality in general and we're concerned about Iris' strictness.
I agree with this. In ESMValCore we have implemented many workarounds for this to make the life of our users easier.
The changes here would make Iris more strict than it is already.
As far as I'm aware, this pull request does not make any changes to Iris behaviour.
Would you have an example so I can understand when this happens?
I even made the hash comparison work for arrays of different dtypes because I initially expected that that would be allowed, but it turns out that even that is not allowed by the current implementation of concatenate, so I could take that out again. Or we can keep it in case you would be interested in being more lenient w.r.t. this kind of differences in the future.
Allowing
NaN
Arrays containing NaNs compare equal with the hashing implementation, I added a test to demonstrate it in 2540fea.
Would it be possible to fall back on 'normal equality' when hash equality is
False?
Yes, it would be easy to add the additional comparison here:
Lines 1077 to 1078 in 3bfea80
however, with the current strict implementation of coordinate comparison, there would be no point in doing so because the result would be the same. I'm not too concerned about the performance impact because in our use case, we expect the input to be compatible enough such that the result of the concatenation is a single cube, so the extra comparison would only happen in exceptional cases when there is something wrong with the input data.
|
The benchmark report is a bit puzzling. I will look into it. Is there already a benchmark for |
iris/benchmarks/benchmarks/merge_concat.py Lines 42 to 61 in d9c4c1d |
bouweandela
added
benchmark_this
⏱️ Performance Benchmark Report: 060ea39Performance shiftsFull benchmark resultsGenerated by GHA run |
bouweandela
removed
the
benchmark_this
bouweandela
added
the
benchmark_this
|
The main reason this is not faster according to the benchmarks appears to be that the Would it be an idea to increase the number of cubes in the benchmark example to make it more realistic? |
⏱️ Performance Benchmark Report: 8d4d9e2Performance shiftsFull benchmark resultsGenerated by GHA run |
bouweandela
added
benchmark_this
⏱️ Performance Benchmark Report: 9789f71Performance shiftsFull benchmark resultsGenerated by GHA run |
bouweandela
commented
Jul 3, 2024
| first_dim_coord.points + np.ptp(first_dim_coord.points) + 1 | ||
| ) | ||
| self.cube_list = CubeList([source_cube, second_cube]) | ||
| source_cube = realistic_4d_w_everything(lazy=True) |
There was a problem hiding this comment.
I enabled lazy=True because it seems more realistic, but the timings are very similar for both cases, maybe because the data is small enough to keep in RAM. Is this change wanted or should I change it back?
bouweandela
commented
Jul 3, 2024
Comment on lines
+49
to
+50
| self.cube_list = CubeList([source_cube]) | ||
| for _ in range(24): |
There was a problem hiding this comment.
The concatenate benchmarks now concatenate 25 cubes, to make the benchmark more realistic but not too time-consuming.
There was a problem hiding this comment.
I tried this branch with one year of high resolution data ( 12 cubes to concatenate) and I get a decrease in time of about 90 seconds with respect to main branch 👍
There was a problem hiding this comment.
Thanks for testing @sloosvel! Do you know what the total time was as well?
There was a problem hiding this comment.
I get around one minute for the parallel concatenation and two minutes / two minutes and a half for the main branch
bouweandela
added
benchmark_this
⏱️ Performance Benchmark Report: f8c1853Performance shiftsFull benchmark resultsGenerated by GHA run |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
🚀 Pull Request
Description
Parallelize the comparison of the values of auxiliary coordinates, cell measures, ancillary variables, and derived coordinates during cube concatenation.
Closes #5750
Consult Iris pull request check list
Add any of the below labels to trigger actions on this PR: