Open RL-S opened 2 months ago
@RL-S - your observations on how the page can be improved sound good. Would you like to take a crack at revising? Ideally, we'd like to have working code for each entry, and an economy of words and ideas.
It really feels like I don't know enough about the internals to answer the questions that I have phrased above. That's why I made that list rather than struggling my way to a potentially wrong or misleading revision.
I think the Wiki page "Hierarchical Parallelism" is potentially very valuable to users, as it tackles some slightly more advanced, but important topics. It's also reasonably well-structured, so I'm not about to propose radical changes.
However, despite being quite familiar with the topic, this page seems much harder to understand than the previous ones - and harder than it needs to be. Here are some of the points that I stumbled over:
a
is supposed to be. Is it a new pattern, or even a builtin? Did I miss a declaration? Why the parentheses? I think I know the answers to these questions by now, but it took a lot of guessing.team_shmem_size
function is defined, but not used. How does it fit into the picture? How and where is it called?set_scratch_size
,PerThread
andPerTeam
are used. I think it would help to addusing Kokkos::PerTeam
to make clear that this isn't pseudo code. I guess these are helper structs to distinguish constructor calls.team_member.team_scratch(0)
? What's the0
there?int& i
)? That's rather non-standard, so if it's intentional, it would be nice if it got a mention/explanation somewhere....
) in examples. It could even enhance other subsections. But using one in the condition (if (...)
) implies to me that it should be either obvious or arbitrary, and in either case I don't know how to square that with the description of the example. For everything beyond this point ('To further illustrate the “parallel region” semantics ...'), I think it can be made clearer what is being shown and how it relates tosingle
.As an aside: Scratch memory seems to be the first instance where allocations need the (in my opinion horrible) C syntax using
sizeof
. If users forgetsizeof
, it's a runtime error. By using template functions, it could both be more elegant and less error prone: e.g. as a free functionget_shmem<double>(team_member, size)
or with deduction through an rvalue parameter, to avoid theteam_shmem.template get_shmem<double>(...)
syntax:team_shmem.get_shmem(double{}, size)
. That way, not providing a type becomes a compile-time error and is thus worlds easier to debug.