-
Notifications
You must be signed in to change notification settings - Fork 279
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
Parallel concatenate #5926
base: main
Are you sure you want to change the base?
Parallel concatenate #5926
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5926 +/- ##
==========================================
+ Coverage 89.75% 89.77% +0.02%
==========================================
Files 90 93 +3
Lines 22929 23072 +143
Branches 5020 5024 +4
==========================================
+ Hits 20580 20714 +134
- Misses 1618 1624 +6
- Partials 731 734 +3 ☔ View full report in Codecov by Sentry. |
⏱️ Performance Benchmark Report: 11b4199Performance shifts
Full benchmark results
Generated by GHA run |
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 dtype
s 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 NaN
s 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
if get_hashes(coord_a.coord) != get_hashes(coord_b.coord): | |
return False |
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
|
🚀 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: