Skip to Content.
Sympa Menu

charm - Re: [charm] [ppl] sdag forall bug?

charm AT lists.cs.illinois.edu

Subject: Charm++ parallel programming system

List archive

Re: [charm] [ppl] sdag forall bug?


Chronological Thread 
  • From: Phil Miller <mille121 AT illinois.edu>
  • To: Jonathan Lifflander <jliffl2 AT illinois.edu>, "Rock, Joseph William" <jwrock2 AT illinois.edu>
  • Cc: "charm AT cs.illinois.edu" <charm AT cs.illinois.edu>
  • Subject: Re: [charm] [ppl] sdag forall bug?
  • Date: Wed, 18 Dec 2013 20:02:09 -0600
  • List-archive: <http://lists.cs.uiuc.edu/pipermail/charm/>
  • List-id: CHARM parallel programming system <charm.cs.uiuc.edu>

I believe the issue described is that the closure in question should be 'opened' at the point where the forall bounds are being evaluated. Jonathan is probably best equipped to comment on this further. If it's as described, we'll open an issue and probably have it fixed shortly. Presumably, we can get this done before the 6.6 release.


On Wed, Dec 18, 2013 at 7:04 PM, Kale, Laxmikant V <kale AT illinois.edu> wrote:
Joseph, I am posting this to the Charm++ mailing list (please post such bug reports there in future). -- Sanjay

----------------------
Dear Professor Kale,

    While working on my project, I noticed a neat little bug with the SDAG 'forall' construct.

    Let's say we want to execute a 'forall' inside a 'when' clause:

when entryMethodA(int totalIterations) {
   forall [i] (1 : totalIterations, 1) {
       //do work here
   }
}

    The variable 'totalIterations' should be in scope for the 'forall' construct. But when we compile, the .def.h code gets a little bit wrong. It'll throw an error like "totalIterations" not in scope.

The offending line looks like: int __first = (1), __last = (totalIterations), __stride = (1);
This is the 'forall''s iteration construct. It appears that there is direct textual substitution from the SDAG code to the generated .def.h code.

Yet, the closures (such as entryMethodA) are passed to this method as parameters. Thus, the 'forall' generated code has access to the parameter called totalIterations. Instead of "totalIterations", though, it would be something like "gen0->getP0()"; (gen0 is the closure object representing the "when entryMethodA" scope)

Were 'forall's intended to have dynamic iteration? Given that it has access to its parent closures' parameters, I think it is in the realm of possibility.
--- 
Laxmikant (Sanjay) Kale         http://charm.cs.uiuc.edu
Professor, Computer Science     kale AT illinois.edu
201 N. Goodwin Avenue           Ph:  (217) 244-0094
Urbana, IL  61801-2302          FAX: (217) 265-6582


_______________________________________________
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





Archive powered by MHonArc 2.6.16.

Top of Page