Hi John --
1) We do have a desire to support void types more fully within the language
than we currently do. We spent a number of years trying to avoid supporting a
void type, but have come around to embracing it, but haven't put in the work to
thread it through everything yet. A case that I've wanted it for at times is
to do:
var foo: computeType();
proc computeType() param {
if (some-param-conditional) then
return int;
else
return void;
}
as a means of avoiding space/storage for a field that I can optimize away in
certain cases at compile-time.
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:
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
