rhornung67
commented
2 years ago From another issue:
This issue is for discussion and future implementation of GPU functionality in Axom Map. Before starting this effort, I wanted to solicit opinions on current plans that I discussed with Arlie Capps on 8/5/2021.
Currently, the plan is to, first, remove all functions from Bucket, Node, and Pair, and implement them separately, thus easing the process of moving data to GPU, at a level where user API is unaffected. Once this is done, I would want to test on CPU, and get a PR out for the change.
After that, I would want to start protyping a secondary class, called MapView. This class would exist to be allocated on GPU to allow interaction with the Map data structure without running into problems with the virtual function tables, which would arise with trying to use the current Map on GPU.
MapView would have one member variable, which is a pointer to the array of Buckets that acts as data storage for Map. It would have functions to be able to read the Map, but no capability to modify it, for this first version. One uncertainty is the question of if it should be allowed to assign new values to key-value pairs -- this would not require importing and updating metadata of changing map size, but would require implementing the locking on GPU.
Does this plan seem reasonable? Are there major problems clear on its surface? Should value assignment be part of the first MapView version, or should focus be put on the simpler read-only model to start? I want to get opinions on answers for these questions before starting development.
Hash maps already have an STL implementation. However, that STL implementation does not play nicely with accelerators, as most STL data structures don’t. This is unfortunate, due to the usefulness of the data structure, especially given the context that methods already exist in the literature for concurrent and GPU-targeted hash maps. This is a gap Axom can fill.
To support use of a hash map for applications such as physics simulations on GPU, Axom needs a hash map that works both on CPU and on supported accelerators. It will need to support access, insertion, and deletion on all supported platforms.
I’ll be implementing this through RAJA and Umpire, as Map in the Core module, starting with a sequential implementation, then moving into the others.