Charm++ parallel programming system

[Nikhil Jain <nikhil.life AT gmail.com>]

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;
};


--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