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

Adds row scatter functionality to dense #1356

Draft
wants to merge 11 commits into
base: develop
Choose a base branch
from
Draft

Conversation

MarcelKoch
Copy link
Member

@MarcelKoch MarcelKoch commented Jun 30, 2023

This PR add row scatter functionality to dense. The target rows can be specified either by a plain array<index_type> or by index_set<index_type>. Note that the index_set implies that the target rows are ordered. Signature:

void row_scatter(const array<index_type>*, LinOp*);
void row_scatter(const index_set<index_type>*, LinOp*);

Todo:

  • dpcpp kernels....
  • maybe have an additive variant like the gather

@ginkgo-bot ginkgo-bot added reg:testing This is related to testing. type:matrix-format This is related to the Matrix formats mod:all This touches all Ginkgo modules. labels Jun 30, 2023
@MarcelKoch MarcelKoch self-assigned this Jun 30, 2023
@MarcelKoch MarcelKoch added the 1:ST:ready-for-review This PR is ready for review label Jul 3, 2023
Copy link
Member

@yhmtsai yhmtsai left a comment

Choose a reason for hiding this comment

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

the function description and one test variable

@sonarqubecloud
Copy link

sonarqubecloud bot commented Aug 3, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot E 1 Security Hotspot
Code Smell A 19 Code Smells

83.9% 83.9% Coverage
4.8% 4.8% Duplication

yhmtsai
yhmtsai previously approved these changes Aug 7, 2023
dim<2> expected_dim{row_idxs->get_num_elems(), this->get_size()[1]};
GKO_ASSERT_EQUAL_DIMENSIONS(expected_dim, this);
GKO_ASSERT_EQUAL_COLS(this, target);
// @todo check that indices are inbounds for target
Copy link
Member

Choose a reason for hiding this comment

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

not sure whether to check the indices here because it will affect the performance. I guess it will have the same runtime as make_row_scatter

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, that would also be my expectation. Perhaps it could be handled by setting an error code in the kernel and then check that afterward. I will need to think if that can be realized.

Copy link
Member Author

Choose a reason for hiding this comment

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

I added an in-kernel check to make sure we don't write out-of-bounds. I'm open to discussions on how to handle that, because I don't think there are many places where we already use something like this. In principle, we could also do this for the gather kernels, although I don't think the issue is as big there, since we are only reading out-of-bounds. Also, we could wrap the check in some #ifdef to disable it perhaps in release builds.

@upsj upsj requested review from upsj and greole September 18, 2023 12:33
Copy link
Collaborator

@greole greole left a comment

Choose a reason for hiding this comment

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

Not a full review yet, just some quick comments/questions?

/**
* Copies this matrix into the given rows of the target matrix.
*
* @tparam IndexType the index type, either int32 or int 64
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
* @tparam IndexType the index type, either int32 or int 64
* @tparam IndexType the index type, either int32 or int64

@@ -539,6 +543,42 @@ class Dense
ptr_param<const LinOp> beta,
ptr_param<LinOp> row_collection) const;

/**
* Copies this matrix into the given rows of the target matrix.
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think this needs to be a bit more expressive in what it means to "copy this matrix into the given rows". Could you add an example here.

Copy link
Member Author

Choose a reason for hiding this comment

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

TBH, since this is the brief description, I think it's fine. But the detailed description is mangled up in the description of the parameters, so perhaps moving that into a separate description block is better.

/**
* Copies this matrix into the given rows of the target matrix.
*
* @tparam IndexType the index type, either int32 or int 64
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
* @tparam IndexType the index type, either int32 or int 64
* @tparam IndexType the index type, either int32 or int64

ptr_param<LinOp> target) const;

/**
* Copies this matrix into the given rows of the target matrix.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Same comment as above.

Comment on lines 2449 to 2450
l<T>({{3.0, 2.7, 6.5},
{0.7, 1.1, 4.0},
Copy link
Collaborator

Choose a reason for hiding this comment

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

I am confused, looks to me like row 0 and 1 should be switched? Doesn't permute_idxs{exec, {1, 0, 4}} say {3.0, 2.7, 6.5} goes into row 1 ?

Copy link
Member Author

Choose a reason for hiding this comment

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

An index set is always ordered. So permute_idxs{exec, {1, 0, 4}} is equivalent to permute_idxs{exec, {0, 1, 4}}. I will add a comment to row_scatter

@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot E 1 Security Hotspot
Code Smell A 18 Code Smells

82.5% 82.5% Coverage
0.0% 0.0% Duplication

warning The version of Java (11.0.3) you have used to run this analysis is deprecated and we will stop accepting it soon. Please update to at least Java 17.
Read more here

@MarcelKoch MarcelKoch force-pushed the row-scatter branch 2 times, most recently from caab3d0 to ecc1b8c Compare December 15, 2023 09:52
@MarcelKoch MarcelKoch requested review from greole and yhmtsai December 15, 2023 10:05
Copy link

Quality Gate Passed Quality Gate passed

The SonarCloud Quality Gate passed, but some issues were introduced.

18 New issues
1 Security Hotspot
83.5% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

@MarcelKoch MarcelKoch added this to the Ginkgo 1.9.0 milestone Aug 26, 2024
Copy link
Member

@upsj upsj left a comment

Choose a reason for hiding this comment

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

LGTM in general, though I would consider making this more strongly typed than just an array, then we also have a well-defined place where we can check for invalid data #770. I think we should already keep an eye out for a potential future scatter_add interface, which may profit from some preprocessing to avoid atomics, which would also encourage a dedicated type.

@MarcelKoch
Copy link
Member Author

@upsj I guess one way to have a more specific type would be to use index_set. But I think the array is the more natural way to describe the indices, so I would just go with it for now. If we decide on a more sophisticated type, I would expect that we can construct that type from an array, so it would not be difficult to add an overload.

@upsj
Copy link
Member

upsj commented Oct 23, 2024

@MarcelKoch my goal is to deprecate the array interfaces in favor of Permutation and related classes in GInkgo 2.0, for consistency it would seem sensible to resolve this topic before adding new interfaces which might need to be deprecated shortly after. index_set IMO is an overly specific type for this purpose, as its storage layout favors a specific kind of subset, which doesn't give any performance benefit in the use cases for row scattering I can think of (namely halo exchange) on general meshes.

@MarcelKoch
Copy link
Member Author

Ok, that makes more sense. I will look into providing a Scatter class instead.

@MarcelKoch
Copy link
Member Author

After looking into it a bit, I don't think adding an extra class for scattering is the right choice at the moment. Without the scatter_add this is a fairly simple operation, so an extra class would be overkill. E.g. if the scatter is not done repeatedly, users would have to write:

RowScatterer<int32>::create(exec, size, idxs)->apply(a, b);

which to me seems to be quite cumbersome, compared to a->row_scatter(idxs, b).

@upsj
Copy link
Member

upsj commented Oct 24, 2024

To me this is an abstraction level mismatch - array is a low-level type with no interpretation of the data associated with it, Dense is a high-level type that gives an interpretation to the underlying data. The array you pass into row_scatter could be anything. Otherwise the same kind of argument could be made for Permutation. IMO we should aim for interfaces that don't mix different abstraction levels.

As for the discussion between scatter_add and scatter, I believe we should consider making scatter_add the default, since otherwise the operation can produce race conditions and non-deterministic behavior trivially.

@MarcelKoch
Copy link
Member Author

Making scatter_add the default will require quite a bit of work. Since I don't think this feature is urgently needed, I will remove this PR from the upcoming release.

@MarcelKoch MarcelKoch removed this from the Ginkgo 1.9.0 milestone Oct 24, 2024
@MarcelKoch MarcelKoch added 1:ST:WIP This PR is a work in progress. Not ready for review. and removed 1:ST:ready-for-review This PR is ready for review labels Oct 24, 2024
@MarcelKoch MarcelKoch marked this pull request as draft October 24, 2024 08:13
MarcelKoch and others added 11 commits February 21, 2025 10:46
currently version with index_set as input is not implemented for devices

Co-authored-by: Yu-Hsiang M. Tsai <[email protected]>
Signed-off-by: Marcel Koch <[email protected]>
Co-authored-by: Yu-Hsiang M. Tsai <[email protected]>
Co-authored-by: Tobias Ribizel <[email protected]>
- add todo
- more specific error message

Co-authored-by: Tobias Ribizel <[email protected]>
Signed-off-by: Marcel Koch <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1:ST:WIP This PR is a work in progress. Not ready for review. mod:all This touches all Ginkgo modules. reg:testing This is related to testing. type:matrix-format This is related to the Matrix formats
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants