Hello, 

> On Jul 12, 2017, at 12:55 PM, Brad Chamberlain <[email protected]> wrote:
> 
> 
>> First, DefaultRectangular has to support arbitrary dimension.
>> Is it important to support arbitrary dimension "column-major"
>> layouts? What about a 3D layout, where only the middle dimension
>> is stored differently from how it works now? As far as I know,
>> people interested in "column major" arrays are talking
>> about 2D arrays / matrices.
> 
> I use row-major and column-major as shorthands for whether the innermost or 
> outermost dimensions are closer together in memory, so I think it extends 
> naturally to higher-dimensional arrays.  As far as I know, this is how others 
> use the terms as well (e.g., I think people say Fortran is a column-major 
> order language even though it also supports higher-dimensional arrays).  We 
> could use less 2D-centric terms for this decision if that seemed more 
> palatable.
> 

Stencils are one example of higher-dimensional arrays where the layout may have 
an impact. Ideally, we would want to select the contiguous dimension, 
considering data reuse patterns and loop order.  But even there, we only care 
about which dimension is the innermost (for spatial locality in cache). The 
ordering of the rest of the dimensions doesn’t matter from a performance 
standpoint. Maybe some TLB improvement but I haven’t seen any work on this. 


> that would need to change, but don't want to take Apan's exploration away 
> from him if he wants to pursue it (that said, I also hesitate to send anyone 
> down into DefaultRectangular.chpl... :(
> For the column-major case, this would need to be something like:
> 
>    proc initialize() {
>      ...
>      blk(1) = 1:idxType;
>      for param dim in 2..rank do
>        blk(dim) = blk(dim-1) * dom.dsiDim(dim-1).length;
>      computeFactoredOffs();
>      const size = blk(rank) * dom.dsiDim(rank).length;
>      ...
>    }
> 

I actually started with this approach. Then backed out of it because (i) I 
wasn’t familiar enough with the module code to figure out exactly which parts 
of the code would have to change/not change (e.g., stridable case in 
getDataIndex) and (ii) I saw this ominous looking comment at the top of the 
initialize routine in DefaultRectangular : "// change name to setup and call 
after constructor call sites; we want to get rid of all initialize functions 
everywhere”. 

So I went with the approach of directly changing the ranges() in the domain and 
just modifying the dsiAccess() functions. 

- Apan
                                   
 
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers

Reply via email to