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

Increase data type flexibility #188

Open
matt-frey opened this issue Jul 28, 2023 · 0 comments
Open

Increase data type flexibility #188

matt-frey opened this issue Jul 28, 2023 · 0 comments
Labels
feature request Used to label a feature request in the issue tracker.

Comments

@matt-frey
Copy link
Member

In GitLab by @vinciguerra_a on Jul 28, 2023, 08:52

The current implementation of support for mixed execution spaces (!188) imposes strict compatibility requirements on data types. However, Kokkos views have greater flexibility than what this enforces. In particular, views can be of different types and yet still be compatible, so long as their memory spaces are accessible from one another. For example, OpenMP and serial views are both host-space views. Assignment between them should be allowed.

IPPL should be adapted to allow greater flexibility with data types. Instead of imposing exactly matching data types, the view types should be free a priori and compatibility should be statically verified using existing Kokkos metaprogramming tools. This will make it possible to use views in different but compatible memory spaces in operations, e.g. scattering OpenMP particles to a serial field.

This will also relax the requirements on using uniform types in certain places.

It should be possible to implement this in a very readable manner using C++20 concepts and constraints. The requires clause could drastically cut down on compilation error message lengths and provide simple static verification of memory space compatibility. The Kokkos team may be considering similar changes in future versions; we should discuss with them whether and how they plan on integrating concepts into their codebase. See example. See also this StackOverflow post.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Used to label a feature request in the issue tracker.
Projects
None yet
Development

No branches or pull requests

1 participant