[SYSTEMDS-3730] Multi-threaded rev reorg operation

[j143]

Basic multi-thread rev implementation.

the rev() Operation

Given a matrix $$( A )$$ of size $$( m \times n )$$, rev() produces a matrix $$( B )$$ of the same dimensions such that:

$$B_{i,j} = A_{m-1-i, j}$$

for all $$( 0 \leq i < m )$$ and $$( 0 \leq j < n )$$.

In words:

• Each row of the output is the corresponding row from the bottom of the input matrix.
• The last row of the input becomes the first row of the output, the second last becomes the second, ... the first row becomes the last.

---

Example

Suppose:

$$A = \begin{bmatrix} 1 & 2 & 3 \\ 4 & 5 & 6 \\ 7 & 8 & 9 \\ \end{bmatrix}$$

Then after rev(A), you get:

$$B = \begin{bmatrix} 7 & 8 & 9 \\ 4 & 5 & 6 \\ 1 & 2 & 3 \\ \end{bmatrix}$$

---

Multi-threaded Implementation

• Split the matrix into chunks of rows.
• Each thread copied its assigned chunk of output rows, each time taking from the appropriate (reversed) input row:
  • If a thread was responsible for output row $$( i )$$, it took input row $$( m-1-i )$$.
• All threads worked in parallel.

---

Summary Table

Input Row $$( i )$$	Output Row $$( m-1-i )$$
0	last row
1	second last row
...	...
m-1	first row

---

test

for every cell $$( (i, j) )$$, output[i][j] == input[rows - 1 - i][j]

[j143]

Hi @mboehm7 , work on invoking the multi-threading part is pending. I verified the logic by directly hard coding number of threads earlier.

could you give some prelim comments on this.

[mboehm7]

Thanks for the patch @j143 - overall the changes are a very good start. Please address the minor comments and then I would merge it in.

[mboehm7]

add a check for a minimum size for parallelization, otherwise fall back to single-threaded as we do it for example in aggregations (LibMatrixAgg).

[j143]

I have added something like 3000_000 in the hop for now, for the tests to trigger the multi-thread.

[mboehm7]

I would recommend to create smaller tasks (e.g., numRows/k/4) which yields better load balancing.

[mboehm7]

create a static method for this kernel which is called from both the single-threaded implementation as well as the multi-threaded implementation

[mboehm7]

remove (I don't think we use this property internally)

[j143]

Hi @mboehm7 , thanks for review. At this point, the multi-threading is working. Can we checkpoint this PR till now and refine further in next PR? or need to update the handling.

Next:

1. CP -> we decide threading, SP -> let the spark decide
2. increase the test coverage
3. use a common static block to use for both the single thread, multi-thread case
4. decide on the blocksize or the threshold at which to trigger to threading

[mboehm7]

Thanks @j143 , I would address then points 3 and 4 in the next days and subsequently merge it in.

[mboehm7]

Thanks for the patch @j143. During the merge, I fixed the remaining stdout printing, moved the parallelization check from compilation to runtime, used the existing common kernels, fixed test errors (dense operations where running into null-pointer exceptions), and consolidated the tests.