charmplusplus
object location services: Share array element location cache above PE level
Original issue: https://charm.cs.illinois.edu/redmine/issues/112
Many PEs on a node may send to a common set of recipients, but will currently keep duplicate copies of where the recipient lives, and require duplicate updates after each recipient migrates. If the location caches could be shared across multiple PEs we could save memory, reduce network traffic, and reduce location overhead. That could either be a node-level cache, or possibly multiple caches per shared memory space to respect things like NUMA domains.
Original date: 2013-04-04 14:42:28
This seems like a pretty obvious engineering change, as opposed to any deep research endeavor - any particular reason to hide it from public view?
Original date: 2017-10-13 14:05:07
AMPI could now benefit from this, and I think many Charm applications already do their own process/node-level location management. We could offer something similar to ckLocal() that returns the C++ pointer to the object if it is within the process. Perhaps it should become a higher priority? Or perhaps we should collect use cases to motivate that?
Moreover, if we were to move in the future to a regime where chares are tied to a process rather than anchored to a specific PE, this would become more necessary. Same goes for dynamically turning on/off cores in a process.
Original date: 2018-05-24 20:00:10
Another use case is supporting sends to chare array elements from [immediate] methods of node groups. That currently fails because the comm thread does not have a location manager or any way of knowing where to send the message.