Charm++ parallel programming system

[Phil Miller <mille121 AT illinois.edu>]

Pure coincidence. Messages in Charm++ are delivered in arbitrary order. If your code relies on processing messages in a particular order, then I suggest writing message identification and sequencing code to enforce it. SDAG is our preferred mechanism for doing that:
http://charm.cs.illinois.edu/manuals/html/charm++/5.html

Also, if you generated that chart yourself, you're putting in a lot of effort reproducing tooling that we've already built. Charm++ has built in tracing, that allows the Projections tool to render highly-detailed timelines of parallel program execution. It's usable for traces up to thousands of cores, and can trace event dependencies and provide many other analyses. You can find it on our downloads page.

On Wed, Oct 30, 2013 at 9:42 AM, François Tessier <francois.tessier AT inria.fr> wrote:

Hello,

On the distributed version of my load balancer, I observe a weird
behavior and I would like to have your opinion about that. My code looks
like this :

--------------------------------------
MyLB::work() {
    for (int i=7; i>=0; i--) { // Desc. order

CProxy_MyLB(thisgroup)[CmiGetFirstPeOnPhysicalNode(i)].DistFunction(i);
    }
}

MyLB::DistFunction (int i) {
    // ... Do some calculation
    fprintf(stderr, "Dist %d", i);
    CProxy_MyLB(thisgroup)[0].CentralFunction(i);
}

MyLB::CentralFunction (int i) {
    fprintf(stderr, "Central %d", i);
    //... Do some calculation
}
-----------------------------------------

And when I execute that, the output is always something like that :

Dist 7
Dist 6
Dist 5
Dist 4
Dist 3
Dist 2
Dist 1
Dist 0
Central 0
Central 1
Central 2
Central 3
Central 4
Central 5
Central 6
Central 7

So, each distributed function is called in desc order as specified by my
for loop. But even if each distributed function calls the central one
with the same order, this central function is carried out in a reverse
way... You'll find as an attachment a Gantt chart which illustrate that
(The R part corresponds to a wait time and the P part corresponds to the
central calculation).

I hope it's clear :) It's not very easy to explain...

How can we explain this behavior?

Thanks

François

--
___________________
François TESSIER
PhD Student at University of Bordeaux
Inria - Runtime Team
Tel : 0033.5.24.57.41.52
francois.tessier AT inria.fr
http://runtime.bordeaux.inria.fr/ftessier/
PGP 0x8096B5FA


_______________________________________________
charm mailing list
charm AT cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/charm