John,

On 03/20/15 09:53, John MacFrenz wrote:> Hi,
 >
 > Now I have got to the point where I can assign different sized chunks 
to different locales, though for now the domain is partitioned only 
along one dimension.

Great to hear!

 > I was wondering if someone could help me with writing and running 
some tests for my domain map, both correctness and performance tests?

We have a framework that exercises common cases and corner cases of 
using a domain map. See these readmes in the Chapel repository on github:

   test/distributions/robust/README
   test/distributions/robust/arithmetic/README

The second README says how to extend the framework to use a new 
distribution - it is a straightforward modification of:

   test/distributions/robust/arithmetic/driver.chpl

 > The code is on github and I'm willing to contribute it if it gets 
developed enough to be included in Chapel.

We welcome your contribution! Please see the first paragraph on our 
developer resources page, which summarizes what's required:

   http://chapel.cray.com/developers.html

 > I guess that many correctness tests for BlockDist could be easily 
modified for this dist. I'd also like to do performance testing versus 
BlockDist.

Sure, any performance test that "uses" BlockDist is great for it. This 
file talks about the support for performance testing that we have:

   doc/developer/bestPractices/TestSystem.txt

The benchmarks whose performance we measure on multiple locales using 
the -perflabel feature of start_test are:

   npb/ep/mcahir/ep.chpl release/examples/benchmarks/hpcc/fft.chpl 
release/examples/benchmarks/hpcc/hpl.chpl 
release/examples/benchmarks/hpcc/ptrans.chpl 
release/examples/benchmarks/hpcc/ra-atomics.chpl 
release/examples/benchmarks/hpcc/stream-ep.chpl 
release/examples/benchmarks/hpcc/stream.chpl 
release/examples/benchmarks/hpcc/ra.chpl 
release/examples/benchmarks/ssca2/SSCA2_main.chpl 
release/examples/benchmarks/miniMD/miniMD.chpl 
studies/hpcc/HPL/vass/hpl.hpcc2012.chpl 
studies/lulesh/bradc/lulesh-dense.chpl studies/nbody/md.xc-keys

 > Also, some questions...
 >
 >   - Can I have the assignment of my domain map to be done by 
reference? Or would it be best to just generate compiler error in 
dsiAssign, since I can't figure how assign-by-value should be done...
 >
 >   - What is the role of dsiClone? Could I just return "this"?

Think of dsiClone as a copy constructor for your Block class instances, 
and dsiAssign as an assignment operator. Let me know if you need me to 
say more here.

Implementing these two pieces of functionality is important for a 
finished product of a domain map. Afaik however, none of our benchmarks 
use them today. So it is fair to leave them unimplemented for now, and 
focus on the other functionality and performance. Feel free to make them 
compiler errors, for example.

>   - Is there a requirement to targetLocDom to have same rank as the 
> distribution (see BlockDist)? (I _recall_ Brad saying that at least not 
> intentionlly, but I'm not sure...) I tried changing that, but couldn't get it 
> compile because of some RAD cache functions.

targetLocDom is an implementation detail that is internal to the Block 
distribution. So I believe there are no requirements about it as far as 
the domain map framework is concerned.

Speaking about the internals of the Block distribution the way it is 
designed, I can see, for example, targetLocDom being 1-d while the 
corresponding domains/arrays being 2-d or more. This would mean that the 
domains/arrays are distributed only along a single dimension. Our Block 
distribution supports this scenario when targetLocDom's extent is 1 
along all but one dimension; we did not write code specific to this case.

Is this what you question is about? If so, yes you can specialize for 
this case, and there may be a way to have the RAD cache compile. I don't 
know off hand what's needed there. It may be easier to support the 
general case instead.

Vassily

------------------------------------------------------------------------------
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

Reply via email to