Charm++ parallel programming system

[Laércio Lima Pilla <llpilla AT inf.ufrgs.br>]

Greetings,

First, thank you all for your help.

To make things work, I implemented each load balancer in a different set of {C,ci,h} files. Some of them are based on a topology-aware base class, which I had to add as a load balancer in Makefile_lb.sh because I did not find a simple way to make Charm++ compile it without changing the Makefile.

I have two centralized load balancers that extend this base class. Each of those is extended in two other load balancers that act as components of a hierarchical load balancer. This was done to provide the correct machine topology to each level of the load balancing tree.

Our hierarchical load balancer uses a three level tree. It is working correctly with most load balancers, with one exception. When I use NucoLBCent as the root load balancer (which extends NucoLB), I get the following error message in the first load balancing call:

[32] Loadbalancing Level 2 (4 children) started at 34.529699, elapsed time 1.743818

[32] HierarchicalLB memUsage: 1862.86KB

[32] Stack Traceback:

  [32:0] +0x32bf0  [0x2aaab2279bf0]

  [32:1] _ZN11_LDCommDescaSERKS_+0xf1  [0x5bd25f]

  [32:2]   [0x5cf14d]

  [32:3] _ZN5CkVecI10LDCommDataE6insertEmRKS0_+0x71  [0x5e15f7]

  [32:4] _ZN5CkVecI10LDCommDataE9push_backERKS0_+0x32  [0x5e0de0]

  [32:5] _ZN12HybridBaseLB11ObjMigratedE9LDObjDataP10LDCommDataii+0x127  [0x5d1317]

  [32:6] _ZN20CkIndex_HybridBaseLB27_call_ObjMigrated_marshall9EPvP12HybridBaseLB+0x137  [0x5d82fb]

  [32:7] CkDeliverMessageFree+0x4e  [0x55879f]

  [32:8]   [0x5588ef]

  [32:9]   [0x558994]

  [32:10]   [0x559ed2]

  [32:11]   [0x559f82]

  [32:12] _Z15_processHandlerPvP11CkCoreState+0x126  [0x55a49a]

  [32:13] CmiHandleMessage+0x49  [0x6204a9]

  [32:14] CsdScheduleForever+0x6e  [0x62080a]

  [32:15] CsdScheduler+0x16  [0x62077a]

  [32:16]   [0x61c8f8]

  [32:17]   [0x61b0d6]

  [32:18] +0x77b6  [0x2aaaaacd37b6]

  [32:19] clone+0x6d  [0x2aaab231ec6d]

This seems very weird to me, as NucoLB works fine as a centralized load balancer, and its intermediary level version has no problems either. I also have no problems such as this one with my other load balancer in its three versions.

Is there any way that you could provide some assistance to me in this matter? What kind of information would be required?

Best regards,

2013/6/11 Gengbin Zheng <gzheng AT illinois.edu>

Hi Laercio,

 I think enough has been explained. I just want to add that you don't have to make fooLB a module if you don't actually need to expose it.

If you  can compile fooLB as .o and link to both foo1LB and foo2LB libraries, it should be fine.

If you want to make fooLB a standalone module (i.e. a useable load balancer), you can use libmodulefoo[12]LB.dep file to specify the dependence of the modules, so you don't have to specify -module fooLB if you already have -module foo1LB or foo2LB in the link command line.

Gengbin

On Mon, Jun 10, 2013 at 7:24 PM, Nikhil Jain <nikhil.life AT gmail.com> wrote:

On further discussion, Phil and I realize that either solution will
*not* work. The macro call, CreateLBFunc_Def, required for every load
balancer generates a static lbinit function (which is declared as a
initnode function in ci files). Having multiple such calls in a .C
file will result in a compilation error. Hence the load balancers will
need their own {.ci,.h,.C} files. Some of these restriction may have a
workaround but none leads to a secure easy solution as of now.

If your intent is to avoid having to attach each LB using a separate
-module argument, once you have written all LBs, you can create a new
module, and extern all LBs from it. Thereafter, if you pass the new
module as an argument, all other LBs will be available. Eg.

module FooLBs {
   extern module FooLB;
   extern module FooLB1;
   extern module FooLB2;
};

PS: Interesting. 

What is required to make such a module? 

How can I inform Charm++ to compile it? 

--Nikhil

On Mon, Jun 10, 2013 at 6:26 PM, Miller, Philip B <mille121 AT illinois.edu> wrote:
> For what Laercio describes, would it make more sense to structure the ci
> file and modules as
>
> module fooLBs {
>   group fooLB { . . . }
>   group fooLB1 { . . . }
>   group fooLB2 { . . . }
> }
>
> Declaring them as separate modules seems to add complexity for no benefit.
>
>
>
> On Mon, Jun 10, 2013 at 6:20 PM, Nikhil Jain <nikhil.life AT gmail.com> wrote:
>>

>> Hi Laercio,
>>
>> Your intention to write all LBs in the same {h,C,ci} file is doable,
>> but requires caution. I will try to explain the significance of
>> -module fooLB during compilation to avoid error. During linking,
>> charmc generates a function to register external modules, which is
>> invoked during charm startup. When  a module is passed as a link time
>> argument, charmc adds a call to register that module  to the generated
>> function. Any external module that is not registered can not be used
>> by the application.
>>
>> In your example, assuming your ci files looks like-
>>
>> module fooLB {
>>      group fooLB {  /*some code*/ };
>> }
>>
>> module fooLB1 {
>>      group fooLB1 : fooLB {  /*some code*/ };
>> }
>>
>> module fooLB2 {
>>      group fooLB2 : fooLB { /*some code*/ };
>> }
>>
>> If only -module fooLB is passed to linker, only fooLB is registered,
>> and the other LBs are not usable. To make the other modules visible to
>> runtime, you will need to extern them from fooLB -
>>
>> module fooLB {
>>     extern module fooLB1;
>>     extern module fooLB2;
>> }
>>
>> Now, if only -module fooLB is passed to linker, all the three module
>> are registered, since fooLB necessitates it.
>>
>> --Nikhil
>>
>>
>> On Mon, Jun 10, 2013 at 4:11 PM, Laércio Lima Pilla
>> <llpilla AT inf.ufrgs.br> wrote:
>> > Greetings,
>> >
>> > I have a quick question for you today: what is the relationship between
>> > modules and load balancers? Does it have to be 1:1?
>> >
>> > I will give an example to make things easier to understand.
>> > Let's say I have a base load balancer class fooLB, which I use to derive
>> > two
>> > other load balancers: fooLB1 and fooLB2.
>> > Could I write them all in the same fooLB.{h,C,ci}, use -module fooLB
>> > when
>> > compiling my application, and call +balancer {fooLB1, fooLB2} when
>> > executing
>> > it, or do I have to write them in different files, pass all modules when
>> > compiling (-module fooLB -module fooLB1 -module fooLB2), and then call
>> > the
>> > load balancer that I want?
>> >
>> > Best regards,
>> >
>> > --
>> > Laércio LIMA PILLA
>> >
>> > PhD Candidate at
>> > - Federal University of Rio Grande do Sul (UFRGS) - Brazil
>> > - University of Grenoble - France
>> > Email: laercio.pilla AT inf.ufrgs.br or laercio.lima.pilla AT gmail.com
>> > Tel: +55 (54) 9973 6313
>> > Website: www.inf.ufrgs.br/~llpilla
>>
>>
>>
>> --
>> "Success may ditch you most of the times, but if you ditch it once :
>> your job is done."
>> Nikhil Jain, nikhil.life AT gmail.com, +1-217-979-0918
>>

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

--
"Success may ditch you most of the times, but if you ditch it once :
your job is done."
Nikhil Jain, nikhil.life AT gmail.com, +1-217-979-0918

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

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

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

--

Laércio LIMA PILLA

PhD Candidate at 

- Federal University of Rio Grande do Sul (UFRGS) - Brazil

- University of Grenoble - France
Email: laercio.pilla AT inf.ufrgs.br or laercio.lima.pilla AT gmail.com 
Tel: +55 (54) 9973 6313
Website: www.inf.ufrgs.br/~llpilla