search

charmplusplus / charm

The Charm++ parallel programming system. Visit https://charmplusplus.org/ for more information.
Apache License 2.0
204 stars 49 forks source link

object location services: scalable cache pre-population #111

Open PhilMiller opened 11 years ago

PhilMiller commented 11 years ago

Original issue: https://charm.cs.illinois.edu/redmine/issues/111

As objects migrate, the system often has sufficient information to know what processors will subsequently send messages to the objects at their new home. Inform those processors of the new locations without creating more overhead than we save in subsequent latency and forwarded messages.

PhilMiller commented 5 years ago

Original date: 2013-06-03 22:19:32

During the core meeting, it became apparent that there's disagreement over how beneficial this work would be. The target use cases are those in which

  1. messages to newly-migrated objects are a large fraction of the overall communication, and
  2. communication patterns exhibit useful persistence or predictability.

In applications where load balancing is rare or only substantial at startup, then condition 1 is weak. This is the case for things like LeanMD.

In applications like ChaNGa where communication partners turn over completely at every iteration, condition 2 is not met.

The proposed relevant case may be things like AMR, where most partners remain the same, but frequent load balancing may be necessary.

PhilMiller commented 5 years ago

Original date: 2013-10-07 19:31:19

Defer for now.

PhilMiller commented 5 years ago

Original date: 2017-12-29 18:19:23

With the move to identify array elements internally with 64-bit IDs, it's now possible for applications to use arbitrary-size index objects to name them. ChaNGa/Paratreet can move to an octree-based decomposition that indexes elements by a bit-string representing the path down the decomposition tree, rather than an integer position along a space-fulling curve. Given such a change, communication between elements of given indices will exhibit persistence, since they will remain spatially close permanently. My understanding is that location updates following tree rebuild and load balancing are currently a noticeable overhead to ChaNGA, so implementing this could be useful.

This may also be useful for Enzo-P/Cello, since I think they use tree-path bit-string indexing.

Per discussion with Eric B, reassigning to Jaemin as the lead student on ChaNGa/Paratreet.