Hi - On 10/11/16, 2:14 PM, "Hui Zhang" <[email protected]> wrote:
>Hello, Brad > > >​Got it, thanks ! > > >Besides, when running on multi-locales, will all the global C variables >defined in the chapel/runtime be shared/accessed by all nodes ?​ No, global C variables declared in Chapel's runtime or in other C code will have 1-copy-per-locale. -michael > >On Tue, Oct 11, 2016 at 1:52 AM, Brad Chamberlain ><[email protected]> wrote: > >Hi Hui -- > > >I believe that what you're seeing here is due to Chapel's injection of >shadow 'const's for variables of simple types (like integers) when they >cross from their declared scope to a parallel scope. Specifically, by >default, each task will get its own 'const' > copy of the variable to prevent accidental race conditions. There's a >short-and-sweet description of them in the 1.11 release notes >(http://chapel.cray.com/releaseNotes/1.11/01-LanguageCompiler.pdf) > though you can also read about them in the language specification and >online documentation ("task intents" and "forall intents" are keywords to >look for). > > >To check this theory, I tried a few things with the 1.14 compiler such as >overriding the default intent for the coforall loop: > > > coforall loc in Locales with (ref gVar) { > >and changing the type of gVar to a type that is passed to tasks by >reference by default (like an atomic variable). With either of those >changes, the output reported '0' every time as you expected. > > >Having said that, I want to caution that we've found ourselves running >into a few cases lately which have caused us to debate (a) whether the >compiler's doing "the right thing" and/or (b) what "the right thing" for >a given case should be. So while this > case seemed to be behaving properly to me, if you run into other cases >that are surprising even taking task/forall intents into account, please >feel encouraged to report or ask about them. > > >It's interesting that you ask about a "locale private" mechanism in >Chapel (i.e., "don't permit remote locales to access this variable"), >which could also help the compiler by saying "I know that all references >to this variable will be local, so don't introduce > any overhead to potentially communicate it if you're uncertain." This >is an idea that comes up fairly regularly, yet which we have not yet >pursued ourselves. I don't think it would be very hard to implement, and >I haven't heard anyone express outright opposition > to it, but I don't think we haven't had a compelling enough proposal or >use case for it to take it on ourselves yet. If you have ideas of how it >should appear syntactically and behave semantically, that would be >interesting (and could be the basis for a good > CHIP). Interestingly, while this question gets asked a lot, I'm not >personally aware of many people who've gotten bitten by accidentally >modifying something remote that they weren't supposed to -- so if you >have war stories like that, we'd be interested to > hear them >​.​ > > > > > >Best wishes, >-Brad > > > >Language and Compiler Improvements - Chapel ><http://chapel.cray.com/releaseNotes/1.11/01-LanguageCompiler.pdf> >chapel.cray.com <http://chapel.cray.com> >C O M P U T E | S T O R E | A N A LY Z E Language and Compiler >Improvements Chapel Team, Cray Inc. Chapel version 1.11 April 2, 2015 > > > >________________________________________ >From: Hui Zhang <[email protected]> >Sent: Monday, October 10, 2016 10:29:12 PM >To: Chapel Sourceforge Developers List >Subject: [Chapel-developers] variable's locale inquiry in parallel block > >Hello, > > >I'm confused about the result of inquiring the variable's locale info >inside a parallel block: >code: >proc main() { > var gVar = 100; > coforall loc in Locales { > on loc { > writeln("Pos2: from >loc.id <http://loc.id>"+loc.id <http://loc.id>+", gVar="+gVar+", >gVar.loc="+gVar.locale.id <http://gVar.locale.id>); > } > } >} >output: >Pos2: from loc.id0, gVar=100, gVar.loc=0 >Pos2: from loc.id2, gVar=100, gVar.loc=2 >Pos2: from loc.id1, gVar=100, gVar.loc=1 > > > >Same results by using forall/begin/cobegin. >Variable gVar is defined in locale 0, if I use serial "for" instead of >"coforall", then the >gVar.locale.id <http://gVar.locale.id> will all print "0", which makes >sense. However, why >locale.id <http://locale.id> of the same variable gVar is changed to be >where it's accessed (loc.id <http://loc.id>) in the parallel cases (while >using coforall/forall/begin/cobegin) ??? > > >Besides, since Chapel has this global view of variables no matter where >they are defined, it seems like a little dangerous to use because any >locale can easily modify the value of a variable that's defined in >another locale if someone > happens to misuse variable names...Is there a locale-specific (like >private to the particular locale) variable mechanism that can prevent >such mistake in Chapel ? > > >Thanks ! > > >Thanks > > > >-- >Best regards > > >Hui Zhang > > > > > > > > > > > > >-- >Best regards > > >Hui Zhang > > > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
