Charm++ parallel programming system

[Harshitha Menon <gplkrsh2 AT illinois.edu>]

In the case of DummyLB, if you take a look at step 3, the step starts at 202.24 but the strategy doesn't start until 222.9. One possible explanation is that stats collection is taking time. Even for  DummyLB, stats are collected. Many times +LBCommOff has helped reduce that time since communication data is not collected. 

The other explanation is that processor 0 (where the central lb work function is called) starts the load balancing step but other processors have not started the step. This could happen if chares on PE 0 called AtSync but chares on some other PEs have not called AtSync yet. You can test this out by having a barrier before the chares call AtSync.

Harshitha

http://harshithamenon.com/

On Mon, Jun 15, 2015 at 10:20 AM, Gopalakrishnan Menon, Harshitha Menon <gplkrsh2 AT illinois.edu> wrote:

If you don't require communication data, can you please try with +LBCommOff runtime option and let me know the effect? GreedyLB and DummyLB doesn't require communication data, so you can use +LBCommOff.

http://harshithamenon.com/

On Mon, Jun 15, 2015 at 9:57 AM, François Tessier <francois.tessier AT inria.fr> wrote:

You'll find as attachment the output of TreeMatchLB. Maybe you would like a version with a specific debug level ?

Dr. François TESSIER
University of Bordeaux
Inria - TADaaM Team
Tel : 0033524574152
francois.tessier AT inria.fr
http://runtime.bordeaux.inria.fr/ftessier/
PGP 0x8096B5FA

On 15/06/2015 16:19, Harshitha Menon wrote:

First duration is for the strategy part. The second one is the total time taken by load balancing which includes stats collection, strategy and the migration. The time when strategy starts is given in the output (51.55 in the case of Greedy).

Can you provide me with the output of TreeMatchLB to help understand the timing.

Thanks
Harshitha

On Jun 15, 2015 6:35 AM, "François Tessier" <francois.tessier AT inria.fr> wrote:

Hello,

I'm looking for some explanations about the measures of time provided by
Charm++ when we call a load balancer. To give an example, I ran some
experiments on a Charm++ application with three load balancers :
DummyLB, GreedyLB and TreeMatchLB. At each LB step, Charm++ gives as
output something like this :

CharmLB> GreedyLB: PE [0] step 0 starting at 51.370771 Memory: 95.647156 MB
CharmLB> GreedyLB: PE [0] strategy starting at 51.553916
[...]
CharmLB> GreedyLB: PE [0] Memory: LBManager: 920 KB CentralLB: 2971 KB
CharmLB> GreedyLB: PE [0] #Objects migrating: 8188, LBMigrateMsg size:
0.52 MB
CharmLB> GreedyLB: PE [0] strategy finished at 52.032098 duration 0.478182 s
CharmLB> GreedyLB: PE [0] step 0 finished at 54.616962 duration 3.246191 s

My question is about the two durations given at the end of the LB step
(duration 1 : 0.478182 s / duration 2 : 3.246191 s). With my
application, the load balancer is called 7 times during the execution.
If I add these durations up :

Duration 1 (strategy finished at... duration ...) :
    GreedyLB      : 2.859333 s
    DummyLB     : 0.001735 s
    TreeMatchLB : 6.762819 s

Duration 2 (step n finished at... duration ...) :
    GreedyLB      : 36.826210 s
    DummyLB     : 122.112121 s
    TreeMatchLB : 136.887350 s

If I look at my own measures in TreeMatchLB, the first duration seems to
correspond to the execution time of the load balancer. Is it true ? What
is the second duration ? How could we explain this 136 seconds for
TreeMatchLB ?

Thanks for your help,

François

--
Dr. François TESSIER
University of Bordeaux
Inria - TADaaM Team
Tel : 0033524574152
francois.tessier AT inria.fr
http://runtime.bordeaux.inria.fr/ftessier/
PGP 0x8096B5FA