[Feature Request] Subview pattern.

[kyungjoo-kim]

Hello,

I use subview in many places. Subview mechanism is good for keeping consistent API interface. However, it is expensive when subview is used inside of a loop. For instance

// rank 2 array
auto multiple_vector_a = View<double**>("a", num_vectors, vector_length);
for (int j=0;j<num_vectors;++j) {
  // rank 1 array, which is a vector
  auto a = subview(multiple_vector_a, i, ALL()); // this is still expensive
  // this function requires rank 1 array
  doSomethingOnVector(a);
}

I believe that many people have similar situation to this. In this situation, subview adds quite overhead as it creates for each iteration. However, the subview pattern is fixed and we can take advantage of it. What I propose is

// rank 2 array
auto multiple_vector_a = View<double**>("a", num_vectors, vector_length);

// this subview creates subview patterns and compute offsets.
// here all view meta data can be constructed without a data pointer. 
// so now null data pointer is returned. 
auto a = subview(multiple_vector_a, FIXED, ALL()); 
for (int j=0;j<num_vectors;++j) {
  // since this already went thgouth subview, it should be unmanaged view
  // and changing the data pointer won't matters
  a.set_data(&multiple_vector_a(i,0,0));
  // this function requires rank 1 array
  doSomethingOnVector(a);
}

Or to ensure subview meta data is consistent, something as follows may be considered:

// for debug mode, validate shape of a and subview structure given 
// for release mode, this only swap the pointer and ignore subview shape arguments 
attach_subview(a, multiple_vector_a, i, ALL);

Kokkos view provides convenience but many people including me may consider to strip out the view when performance matters. This subview mechanism can reduce overhead and still provide luxury of view.

[hcedwar]

Consider something like

decltype( subview(a,i,ALL,ALL) ) aa ;
for ( ... ) {
  assign_subview( aa , a , i , ALL , ALL );

[kyungjoo-kim]

I am fine as long as I can reduce subview overehad to a simple pointer swapping.

So, the "decltype" is completely portable for everywhere, right ?

[hcedwar]

Dimensions of subview remain fixed, only the underlying address changes at each iteration.

[kyungjoo-kim]

@hcedwar

Just regular ping to see how this is going on. In Andrew's implementation of line smoother, this capability would improve performance a bit.

[ambrad]

In the line smoother solve phase, which is O(nnz) and so very sensitive to overhead, using raw pointers instead of subview gives a speedup of 1.2 to 1.5 for block sizes of interest. The solve phase is often the most time consuming by an order of magnitude or more.

[hcedwar]

FYI: @ambrad @kyungjoo-kim , this is being tested now to go into the next promotion.

[ambrad]

Nice. @mhoemmen and @mndevec are probably interested in this, as well.

[mhoemmen]

@ambrad It could be nice to have this feature for sparse matrices, though I think it's most critical for (small dense) block sparse matrices.