Charm++ parallel programming system

[François Tessier <francois.tessier AT inria.fr>]

Hello Harshitha,

I ran  a couple of experiments with and without +LBCommOff on 256 cores. I noticed a few things :
    - When using +LBCommOff, the "time step" is stable for each load balancer.
    - If I remove +LBCommOff, I obtain sometimes the same "time step" and sometimes an higher value. It varies from one execution to another.
    - With TreeMatchLB, when I use +LBCommOff the whole execution time is reduced. On some experiments without +LBCommOff, the "time step" is the same as the execution without the option but the total execution time is higher.

I'll carry out more experiments to understand what happens. It could be a real issue if the gathering of communication data takes to much time...

Best regards,

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

On 15/06/2015 17:20, Harshitha Menon 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

Attachment: signature.asc
Description: OpenPGP digital signature