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

Support different lshape maps in binary ops #887

Closed

Conversation

ClaudiaComito
Copy link
Contributor

@ClaudiaComito ClaudiaComito commented Nov 5, 2021

Description

Implementing support for binary operations on distributed DNDarrays of same shape, same split, but different distribution map, i.e.:

a =  ht.ones(10, split=0)
b = ht.zeros(10, split=0)
c = a[:-1] + b[1:]

Issue/s resolved: #880

Changes proposed:

  • redistribute_ one of the two DNDarrays to match the distribution map of the other.
  • expand tests
  • include a warning in the __binary_op documentation

Type of change

  • New feature (non-breaking change which adds functionality)

Memory requirements

Memory requirements are consistent with the extra memory requirements of DNDarray.redistribute_().

Performance

Performance slow-down is consistent with redistributing a DNDarray before a binary operation.

Due Diligence

  • All split configurations tested
  • Multiple dtypes tested in relevant functions
  • Documentation updated (if needed)
  • Updated changelog.md under the title "Pending Additions"

Does this change modify the behaviour of other functions? If so, which?

no, but it redistributes one of the operands in place.

@ClaudiaComito ClaudiaComito marked this pull request as draft November 6, 2021 04:30
@ClaudiaComito ClaudiaComito added this to In progress in Earth System Modeling support via automation Nov 6, 2021
@ClaudiaComito ClaudiaComito added this to the 1.2.x milestone Nov 6, 2021
@ben-bou ben-bou force-pushed the features/880-bin_op_different_distribution branch from 1958470 to cb053e6 Compare November 7, 2021 22:24
b = ht.zeros(10000, split=0)
c = a[:-1] + b[1:]
```
In such cases, one of the operands is redistributed IN PLACE to match the distribution map of the other operand.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why in-place? This means that a binop can manipulate its arguments

if (
t2.split is not None
and not (t2.lshape_map[:, t2.split] == t1.lshape_map[:, t1.split]).all()
and t2.lshape_map[:, t2.split].sum() == t1.lshape_map[:, t1.split].sum()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The last condition is not necessary:

  1. output_shape is already determined, so shapes are compatible
  2. no (shape)broadcasting is happening in the split dimension because of lines 152 to 175
    -> elements in split-dimension are already equal

@ClaudiaComito
Copy link
Contributor Author

Changes addressed in #902 by @ben-bou

Earth System Modeling support automation moved this from In progress to Done Jan 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Binary operations: Support differing lshape-maps
2 participants