Project

General

Profile

Feature #112

Feature #180: object location services: improve implementation and protocol

object location services: Share array element location cache above PE level

Added by Phil Miller over 6 years ago. Updated about 1 year ago.

Status:
New
Priority:
Normal
Assignee:
Category:
SMP
Target version:
Start date:
03/15/2013
Due date:
% Done:

0%


Description

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.


Related issues

Related to Charm++ - Feature #185: provide backup implementations of std::unordered containers Rejected 07/01/2013

History

#1 Updated by Ramprasad Venkataraman over 6 years ago

  • Assignee set to Ramprasad Venkataraman

#2 Updated by Ramprasad Venkataraman over 6 years ago

  • Private changed from No to Yes

#3 Updated by Phil Miller over 6 years ago

This seems like a pretty obvious engineering change, as opposed to any deep research endeavor - any particular reason to hide it from public view?

#4 Updated by Ramprasad Venkataraman over 6 years ago

  • Subject changed from Share array element location cache information above PE level to object location services: Share array element location cache above PE level
  • Parent task set to #180

#5 Updated by Eric Bohm almost 6 years ago

  • Assignee changed from Ramprasad Venkataraman to Eric Bohm

#6 Updated by Eric Bohm almost 6 years ago

  • Target version changed from 6.6.0 to 6.7.0

#7 Updated by Nikhil Jain over 3 years ago

  • Target version changed from 6.7.0 to 6.8.0

#8 Updated by Eric Bohm over 2 years ago

  • Target version changed from 6.8.0 to 6.8.1

#9 Updated by Sam White over 2 years ago

  • Category set to SMP
  • Private changed from Yes to No

#10 Updated by Eric Bohm almost 2 years ago

  • Target version changed from 6.8.1 to 6.9.0

#11 Updated by Sam White almost 2 years ago

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.

#12 Updated by Eric Bohm over 1 year ago

  • Target version changed from 6.9.0 to 6.9.1

#13 Updated by Eric Bohm over 1 year ago

  • Target version changed from 6.9.1 to Unscheduled

#14 Updated by Sam White about 1 year ago

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.

Also available in: Atom PDF