Charm++ parallel programming system

[Sam White <white67 AT illinois.edu>]

Hi Jakub,

1. Implementing a PUP method or using PUPbytes is mandatory only for classes that need to be serialized (for some reason) by the runtime. So any types that will be used as arguments to parameter marshalled entry methods need them, and most types that will be owned by a chare array element that will be migrated (for load balancing or checkpoint/restart) need them. In general, most classes should have PUP methods. But they don't need to have them if you know they will not be serialized for any reason.

Some potential reasons for not needing PUP routines are:
- You know the class will only be used locally and transiently within an entry method.
- Your application is not using checkpoint/restart or load balancing, and the type is not used in a parameter marshalled entry method.
- An instance of your type is owned by a migratable chare array element, but you know that it is cheaper/faster to tear down and rebuild the instance before and after migration rather than serialize/migrate it.

2. SDAG is a convenient syntax for expressing common communication patterns. It works by buffering early messages until the receiving chare is ready for them, and we have tuned these buffering mechanisms for performance in common scenarios. You can implement the same buffering logic yourself in the application. If you have a case where you are beating SDAG's performance we'd be interested in hearing about it to see if we can match that. In general, any performance difference here should be very small.

3. ckLocal() is a PE-level construct. Object location management and migration also happen currently at the PE-level, so an object will never migrate away in the background or middle of a normal application chare's execution. You are correct that you need to be careful about saving the pointer returned by ckLocal() beyond the scope of an entry method, since an object might migrate away between entry method executions. We recommend refreshing any local object pointers anytime things could have migrated for this reason. Most scientific applications written in Charm++ use persistence-based load balancing via AtSync(), so their developers know when migration can possibly happen, and use ResumeFromSync(), ckAboutToMigrate(), and ckJustMigrated() to refresh any saved local pointers around migrations.

Hope that answers your questions, let us know if you have any follow-ups. Thanks!
Sam

On Sun, Sep 15, 2019 at 9:48 AM Jakub Homola <jakub.homola AT vsb.cz> wrote:

Hello,

I am learning to use Charm++ and would like to ask some questions which I haven’t found answers to.

 

Is implementing a pup method in a chare class or using the PUPbytes(myClass) macro mandatory? It seems to me like it should be, but I have not found such a statement in the manual nor any tutorial, nor anything about some default behaviour.

 

Are there any performance benefits when using Structured Dagger constructs compared to manually implementing the same functionality?

 

I have seen that function someProxy.ckLocal() returns a non-null pointer if the object corresponding to that proxy is on the same PE as the one calling the ckLocal function. Does it even make sense to implement some functionality around it, when that object can migrate immediately after the ckLocal function returned, making the returned pointer invalid? Or it is somehow possible to prevent it from migrating away for some time or something?

 

Thanks in advance for the answers,

Jakub Homola