Project

General

Profile

Cleanup #1948

Rename Charm's graph.h to something less generic

Added by Sam White 3 months ago. Updated 2 months ago.

Status:
Merged
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
07/19/2018
Due date:
% Done:

0%


Description

src/util/graph.h ends up in Charm's include/ directory, meaning that if an application tries to #include "graph.h" it might get Charm++'s graph.h instead of its own or something else. This happens when building the Zoltan library on top of AMPI.

Our graph.h is apparently part of the load balancing framework, according to comments in it, even though it's not in ck-ldb/. I'm not even sure if it's used.

History

#1 Updated by Matthias Diener 3 months ago

Seems to be used only by RecBisectBfLB.

#3 Updated by Matthias Diener 3 months ago

RecBisectBfLB does not seem to compile, and I think we should consider removing RecBisectBfLB and the graph.h stuff.

#4 Updated by Evan Ramos 3 months ago

Matthias Diener wrote:

RecBisectBfLB does not seem to compile, and I think we should consider removing RecBisectBfLB and the graph.h stuff.

If the load balancing subgroup is okay with this, sounds good to me.

#5 Updated by Kavitha Chandrasekar 3 months ago

RecBisectBfLB works okay after updating num_partitions to use CkNumPes(). It seems to balance load okay on a single node. Here's a sample run.

$ ./stencil3d 128 64 +ppn 4 +balancer RecBisectBfLB +LBDebug 1
Charm++: standalone mode (not using charmrun)
Charm++> Running in SMP mode: 1 processes, 4 worker threads (PEs) + 1 comm threads per process, 4 PEs total
Charm++> The comm. thread both sends and receives messages
Converse/Charm++ Commit ID: v6.8.2-758-g1d39b80c5
Charm++> scheduler running in netpoll mode.
CharmLB> Verbose level 1, load balancing period: 0.5 seconds
CharmLB> Load balancer assumes all CPUs are same.
Charm++> Running on 1 hosts (2 sockets x 4 cores x 1 PUs = 8-way SMP)
Charm++> cpu topology info is gathered in 0.001 seconds.
CharmLB> RecBisectBfLB created.

STENCIL COMPUTATION WITH BARRIERS
Running Stencil on 4 processors with (2, 2, 2) chares
Array Dimensions: 128 128 128
Block Dimensions: 64 64 64
[1] Time per iteration: 0.028574 0.059614
[2] Time per iteration: 0.144010 0.203675
[3] Time per iteration: 0.141648 0.345374
[4] Time per iteration: 0.143779 0.489203
[5] Time per iteration: 0.141399 0.630652

CharmLB> RecBisectBfLB: PE [0] step 0 starting at 0.713235 Memory: 40.465790 MB
CharmLB> RecBisectBfLB: PE [0] strategy starting at 0.757647
[0] RecBisectBfLB strategy
[0] RecBisectBfLB: graph converted
returning from partitioner strategy
CharmLB> RecBisectBfLB: PE [0] Memory: LBManager: 810 KB CentralLB: 3 KB
CharmLB> RecBisectBfLB: PE [0] #Objects migrating: 4, LBMigrateMsg size: 0.00 MB
CharmLB> RecBisectBfLB: PE [0] strategy finished at 0.757679 duration 0.000032 s
CharmLB> RecBisectBfLB: PE [0] step 0 finished at 0.769063 duration 0.055828 s

[6] Time per iteration: 0.267664 0.898375
[7] Time per iteration: 0.015388 0.913812
[8] Time per iteration: 0.120018 1.033888
[9] Time per iteration: 0.120761 1.154704
[10] Time per iteration: 0.119944 1.274706

#6 Updated by Evan Ramos 2 months ago

  • Assignee set to Evan Ramos
  • Status changed from New to Implemented
  • Tracker changed from Bug to Cleanup

#7 Updated by Sam White 2 months ago

  • Status changed from Implemented to Merged
  • Target version set to 6.9.0

Also available in: Atom PDF