> and am particularly confused by the fact that your argument 'bar' shadows the
> class field 'bar' and what that's supposed to mean
I had the impression that if a class has a generic field (bar in this case), a
constructor argument with the same name automatically assigns the type and
value. At least that is how it seems to work.
> 2) I'm not sure I'm understanding the goal of what you're trying to achieve
> here (and am particularly confused by the fact that your
> argument 'bar' shadows the class field 'bar' and what that's supposed to
> mean). 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:
Okay, here is a bit more concrete example:
class Foo {
const bar;
proc Foo(bar = 0) { }
proc DoSomething(x: int) {
if bar.type != int then {
bar.writeln("Here is some debug information about DoSomething");
}
return 3*x;
}
}
const A = new Foo();
const B = new Foo(bar=stdout);
A.DoSomething(42);
B.DoSomething(42);
The actual situation is a bit more complicated, though. It is about acquiring
execution times from my distribution, and I want to optimize cases where user
doesn't want to gather that information. The above could be written as:
class Foo {
const bar;
param useBar;
proc Foo(bar = 0, param useBar: bool) { }
proc DoSomething(x: int) {
if useBar then {
bar.writeln("Here is some debug information about DoSomething");
}
return 3*x;
}
}
const A = new Foo(useBar=false);
const B = new Foo(bar=stdout, useBar=true);
A.DoSomething(42);
B.DoSomething(42);
So in the first case one constructor argument is required, in the second cast
two. I feel that the way to create new Foo in the first code is more
user-friendly than the one in second code, but that might be just a personal
preference...
> myfoo.foo();
>
> and:
>
> myfoo.foo(bar=2);
>
> via a param query (name/syntax TBD and we're open to suggestions).
>
> -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
