Add MultiReducer

[MrBurmark]

Add runtime sized reducer

Add a runtime sized reducer based on design mentioned in #1648.

• This PR is a feature
• It does the following:
  • Adds MultiReducer at the request of myself and others
• TODO
  • [x] testing for random bin per iterate
  • [x] testing for all bins per iterate
  • [x] testing for some bins per iterate
  • [x] testing for cuda/hip that would go over available shmem
  • [x] testing with forall
  • [x] testing with kernel
  • [x] testing with launch
  • [x] cuda/hip tuning parameters
  • [x] cuda/hip tuning
  • [x] fallback for cuda/hip if shmem unavailable
  • [x] Figure out nvcc compile issue
  • [ ] Figure out intel correctness problem with omp::Auto
  • [ ] omp_target implementation
  • [ ] sycl implementation
  • [ ] new reducer interface

[artv3]

Adding an example could be really nice too! You can probably just take one from the unit test.

[MrBurmark]

Here is the nvcc error output.

.../RAJA/test/functional/forall/multi-reduce-basic/tests/test-forall-basic-MultiReduce.hpp:94:394: error: '__T6' was not declared in this scope
     RAJA::forall<EXEC_POLICY>(seg, [=] RAJA_HOST_DEVICE(IDX_TYPE idx) {
                                                                                                                                                                                                                                                                                                                                                                                                          ^

[MrBurmark]

Here is the nvcc error output.

.../RAJA/test/functional/forall/multi-reduce-basic/tests/test-forall-basic-MultiReduce.hpp:94:394: error: '__T6' was not declared in this scope
     RAJA::forall<EXEC_POLICY>(seg, [=] RAJA_HOST_DEVICE(IDX_TYPE idx) {
                                                                                                                                                                                                                                                                                                                                                                                                          ^

I worked around this by putting the enable_if in the return value.

[MrBurmark]

The docs are build here https://raja.readthedocs.io/en/feature-burmark1-multireduce/. @LLNL/raja-core

[MrBurmark]

It looks like the tests on ruby are failing because std::tuple_size is not defined for camp::tuple, but I fixed that in camp and updated the camp submodule in my branch. Could the CI still be using an older version of camp?

[rhornung67]

It looks like the tests on ruby are failing because std::tuple_size is not defined for camp::tuple, but I fixed that in camp and updated the camp submodule in my branch. Could the CI still be using an older version of camp?

That's likely. Did your fix appear in the v2024.07.0 camp release? The camp spack package in the radiuss-spack-configs submodule has not been updated -- https://github.com/LLNL/radiuss-spack-configs/blob/037ee671622bd3ec2ff955ced356b59dc96fec58/packages/camp/package.py#L111spack-configs. And there is no new RAJA version to identify in the RAJA spack package yet: https://github.com/LLNL/radiuss-spack-configs/blob/037ee671622bd3ec2ff955ced356b59dc96fec58/packages/raja/package.py#L198

It's kind of a chicken and egg thing. Here's a suggestion....

1. Make a PR branch in radiuss-spack-configs that adds the new camp version info in the camp and raja packages.
2. Change the radiuss-spack-configs submodule in your RAJA PR branch to point at that branch.

If that works we can go with those changes to get your PR merged. Then, we can do a RAJA release. After that, we can update the version info in the raja package in the radiuss-spack-configs PR branch and get that merged. We will move to the latest radiuss-spack-configs for the RAJA RC branch.

@adrienbernede or @davidbeckingsale do either of you have a better idea for handling this?

[MrBurmark]

That's likely. Did your fix appear in the v2024.07.0 camp release?

Yes, the changes are in the 2024.07.0 release of camp.

[rhornung67]

Any idea how the Azure tests are passing?

Did my suggestion make sense?

[MrBurmark]

Any idea how the Azure tests are passing?

Are they just using the submodule instead of spack?

Did my suggestion make sense?

Ya, I'm working on making a branch

[rhornung67]

Yes, you are correct. Azure tests do not use Spack.

If you have any questions while working through this, please let me know.

[MrBurmark]

If you have any questions while working through this, please let me know.

I made a radius-spack-configs branch and pointed this branch at it, we'll see what happens.

[rhornung67]

@MrBurmark third time is the charm? 😄

[MrBurmark]

@MrBurmark third time is the charm? 😄

*crosses fingers*