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
