Okay, seems I hadn't properly read your mail before replying... > It looks like it could be vaguely related to another feature that we'd like > to support, so I'll throw it out just in case: > We've talked about adding support for an ability to query whether or not an > argument was provided at the > callsite vs. provided by an end-user so that one could differentiate between: > > myfoo.foo(); > > and: > > myfoo.foo(bar=2); > > via a param query (name/syntax TBD and we're open to suggestions).
That is pretty much what I'd like to do. However, I'd like to do such queries in methods of a class to see if certain argument was passed to the constructor. > -Brad > > ________________________________________ > From: John MacFrenz [[email protected]] > Sent: Tuesday, March 10, 2015 11:33 AM > To: [email protected] > Subject: Re: Variable Block Distributions > > Hi, > > Again a new question. Currently I have a following kind of code: > > class foo { > const bar; > param enableBar; > > proc foo(bar, enableBar) { > if enableBar then { > // Do something with bar... > } else { > // Do something else... > } > } > } > > However, I got an idea to factor enableBar out by using the type of the bar > in the conditional. Like: > > class foo2 { > const bar; > > proc foo(bar = 0) { > if bar.type != int then { > // Do something with bar... > } else { > // Do something else... > } > } > } > > The above solution seems to work fine. However, the thing that bugs me is > that type of int is used to indicate to bar is not to be used. For my need > current need this is not a problem, since if bar is used it will never be an > integer. However, this solution seems somehow dodgy and semantically off. My > initial thought was to use the void type to indicate that bar is not to be > used, however I could not figure a way to do that. So... > - Would it be valid Chapel to somehow use void instead of int in the above > example? > - If it would be, does the compiler currently support this? > > 06.03.2015, 21:17, "Vassily Litvinov" <[email protected]>: >> John, >> >> Responding to your array assignment question. In Chapel, arrays are >> indeed assigned "by value". The ref intent means that the formal >> '_initArr' refers to the actual 'initArr'. So assigning into the formal >> _initArr is the same as assigning into the actual initArr. >> >> By contrast, if you passed initArr by 'in' intent, the formal would be a >> copy of the actual. So the assignment would update the copy, leaving the >> actual initArr unchanged. >> >> Note that you do not need to write 'ref' explicitly in this case, >> because for arrays the blank intent is equivalent to 'ref'. >> >> Vass >> >> On 03/06/15 01:54, John MacFrenz wrote: >>> Hi, >>> >>> Thanks, this seemed to solve the problem. For the class case I ended up >>> doing: >>> >>> proc DoSomething() { >>> _DoSomething(initArr, resArr); >>> } >>> >>> proc _DoSomething(ref _initArr, ref _resArr) { >>> forall ... { >>> .... >>> } >>> _initArr = _resArr; >>> } >>> >>> Now I'm a bit confused about the assignment in the code above. Since >>> arrays were passed with ref intent I thought that _initArr = _resArr would >>> result in those both now referencing to the same array. However seemingly >>> assignment in still done by value, despite the ref intent. So is this how >>> it is supposed to go? >>> >>> I also noticed that with --cache-remote number of gets drops to about >>> 2000. I'd be interested to hear how this is done, since in that specific >>> example, each locale needs 8000 values from the other (when using two >>> locales). However the results of the calculation were still correct. >>> >>> 06.03.2015, 02:34, "Vassily Litvinov" <[email protected]>: >>>> John, >>>> >>>> This communication issue is not specific to domains/arrays, although >>>> it is more visible with domains/arrays. >>>> >>>> Consider this simple example: >>>> >>>> class TestClass { >>>> var initArr: [...] real; >>>> proc DoSomething() { >>>> forall ... { >>>> ... this.initArr[...] ... >>>> } >>>> } >>>> } >>>> >>>> const TC = new TestClass(); >>>> TC.DoSomething(); >>>> >>>> In order to compute "this.initArr[...]", currently we need to get >>>> the pointer to initArr (meta-)data. That pointer is stored in 'this' >>>> object. >>>> >>>> On those iterations of the 'forall' that are on a different locale >>>> than 'this', fetching that pointer from 'this' results in a remote get. >>>> This is, I believe, what bytes you here. >>>> >>>> Avoiding these remote fetches is a simple optimization, which we >>>> do not do currently. As a workaround, you can pass 'initArr' explicitly >>>> into DoSomething(): >>>> >>>> class TestClass { >>>> var initArr: [...] real; >>>> proc DoSomething(initArr) { >>>> forall ... { >>>> ... initArr[...] ... // reference the formal >>>> } >>>> } >>>> } >>>> >>>> const TC = new TestClass(); >>>> TC.DoSomething(TC.initArr); // pass initArr >>>> >>>> As an aside, since in your example initArr and resArr are >>>> Block-distributed, they are "privatized". So what we really fetch >>>> is their integer 'pid' fields; the rest is done locally. >>>> >>>> If my explanation does not seem to help, please let us know. >>>> >>>> Vass >>>> >>>> On 03/05/15 14:18, John MacFrenz wrote: >>>>> Hi, >>>>> >>>>> While writing a test case to compare my new distribution with the >>>>> block distribution I ran into some performance problems when having >>>>> distributed domains, arrays and domainmaps inside a class. >>>>> >>>>> If domain map, domains and arrays are members of a class, and >>>>> computing is done in a method, it seems to generate much more >>>>> communication than when not using class. Gets on the second locale are >>>>> 8022 without classes and 20222 using the class thing on my computer. >>>>> --cache-remote reduces communications, but the ratio of gets (or get_nbs) >>>>> stays same. >>>>> >>>>> Code demonstrating this problem is as an attachment. I ran the test >>>>> with two locales. Notice the number of gets on the second locale when >>>>> using the class approach. >>>>> >>>>> Is this just a limitation of chapel implementation, or does the class >>>>> approach require some special tricks...? > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Chapel-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/chapel-users ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Chapel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-users
