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
Convert PreconditionChebyshev::set_initial_guess_kernel to Kokkos #15091
Convert PreconditionChebyshev::set_initial_guess_kernel to Kokkos #15091
Conversation
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.
Looks good to me.
Kokkos::RangePolicy<typename MemorySpace::kokkos_space::execution_space, | ||
Kokkos::IndexType<types::global_dof_index>> | ||
policy(0, n_local_elements); | ||
Kokkos::parallel_for( |
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.
I hope this won't be the new standard how to write code in deal.II...
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 you mind elaborating?
Kokkos::IndexType<types::global_dof_index>> | ||
policy(0, n_local_elements); | ||
Kokkos::parallel_for( | ||
"PreconditionChebyshev::set_initial_guess", |
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.
It really feel strange to specify a string for a function call.
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.
Well, this helps Kokkos
' tools for profiling.
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.
One wished that they had made that the last argument to the function, with a default to ""
. But having it is a good idea.
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.
You can omit the label anyway (but that's not recommended since it makes identifying kernels in Kokkos
tools, Nsight Systems, VTune, etc. much harder).
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.
Looks good to me. I also think that passing strings is much uglier than having the right C++ function name to start with, but lambdas are what they are. On the performance side, these are big enough loops and not in the innermost level of algorithms. Hence I see no problem (my insistence is because the string is more than 22 characters, so it will allocate memory I assume, and thus have a minimal run time of ~3e-7 seconds).
We could of course replace the lambda with a functor class, but the problem really is that the actual kernel launched is buried in |
Is it worth just standardizing on passing |
We tried something similar in a different project but the problem is that the names are too long. You can't read them easily in your profiler. Like Daniel said the name is optional but it's very useful. |
OK, let's go with this solution, which is a good progress. |
No description provided.