Cleanup #1948

Rename Charm's graph.h to something less generic

Added by Sam White about 1 year ago. Updated 11 months ago.

Target version:
Start date:
Due date:
% Done:



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.


#1 Updated by Matthias Diener about 1 year ago

Seems to be used only by RecBisectBfLB.

#3 Updated by Matthias Diener 12 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 12 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 12 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.

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 11 months ago

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

#7 Updated by Sam White 11 months ago

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

Also available in: Atom PDF