Fixed slow COO SpMV for the OpenMP executor

[thoasm]

Changed the order of the loops in the OpenMP COO SpMV, so the pragma is in the outer loop.

I ran some tests on my laptop (matrix: 5320 x 2310, 100 right hand sides), 5 consecutive applys for each executor (not averaged, time shown is the sum over all 5 passes):

Before this PR (current develop):
Duration ref [us]: 1464703
Duration omp [us]: 76439644

With this PR:
Duration ref [us]: 1421583
Duration omp [us]: 3172356

I was able to run it on the CI system (OMP_NUM_THREADS=10), and I get these results (same settings as on my laptop, listed above):

Before this PR:
Duration ref [us]: 3134603
Duration omp [us]: 70496128

With this PR:
Duration ref [us]: 3246514
Duration omp [us]: 1227014

Now, same test with OMP_NUM_THREADS=40:

Before this PR:
Duration ref [us]: 3132254
Duration omp [us]: 315196010

With this PR:
Duration ref [us]: 3129671
Duration omp [us]: 881428

So, I would say we keep the pragmas for the number of right hand sides.

Closes #339

[codecov]

Codecov Report

Merging #340 into develop will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff            @@
##           develop     #340   +/-   ##
========================================
  Coverage    98.22%   98.22%           
========================================
  Files          237      237           
  Lines        17993    17993           
========================================
  Hits         17673    17673           
  Misses         320      320

Impacted Files	Coverage Δ
omp/matrix/coo_kernels.cpp	100% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1600c6d...704e008. Read the comment docs.

[yhmtsai]

It leads a race condition because c->at(coo_row[i], j) with different i can be the same.
Change the for loop order can avoid this problem.

#pragma amp parallel for
for (size_type j = 0; j <num_cols; j++) {
    for (size_type i = 0; i < a->get_num_stored_elements(); i++) {
        ...
    }
}

If the previous implementation is slow due to too many openMP instructions, this implementation should be also faster than previous one.

[thoasm]

@yhmtsai You are correct, good catch.

[thoasm]

@yhmtsai I am currently testing the variant you proposed, but on my laptop, it is still slower than the reference version.
I think I might go without any pragmas in the end, depending on the result of the CI system.

[thoasm]

I did quite a lot of benchmarks (see the description), and I think the current version should be acceptable (at least on clusters). On my laptop, it is still slower.
It might be because the laptop has less memory channels, higher frequency on the CPU or something similar.

But I would go with the solution that works best on the CI system since it represents HPC clusters better than a laptop.