cudax::group splits the previous group into several new groups that are completely independent. Although this gives the user a lot of flexibility, it often needs some additional resources. For example groups of warps within a block need an array of barriers for synchronization. This adds overhead in some of the more simpler cases when all of the created groups can use the same synchronization point.
That's why I'd like to provide a tied group (or a different name) that also splits the previous group into several new groups, but they share the synchronization points. For example you can split warps or threads within a block into groups, but use __syncthreads() for synchronization.
This group shouldn't support optional participation, because even threads that are not part of any group would have to invoke an algorithm with some garbage values.
cudax::groupsplits the previous group into several new groups that are completely independent. Although this gives the user a lot of flexibility, it often needs some additional resources. For example groups of warps within a block need an array of barriers for synchronization. This adds overhead in some of the more simpler cases when all of the created groups can use the same synchronization point.That's why I'd like to provide a tied group (or a different name) that also splits the previous group into several new groups, but they share the synchronization points. For example you can split warps or threads within a block into groups, but use
__syncthreads()for synchronization.This group shouldn't support optional participation, because even threads that are not part of any group would have to invoke an algorithm with some garbage values.