r.patch: implement parallelization with OpenMP

[aaronsms]

Checklists before merging:

• code review
• CI passes
• performance section in documentation
• confirm values in test are from the old version (run new tests with old code)
• run tests without openmp
• visual check of results with custom data ("looks good" with non NC SPM dataset)
• check that it works with really large data (16B cells)
• run multi-core benchmark (no degraded performance with many threads)
• run one core benchmark on many resolutions or many cell
• rebase to main

[HuidaeCho]

row = 0; to avoid

main.c:250:5: warning: ‘row’ may be used uninitialized in this function [-Wmaybe-uninitialized]
     G_percent(row, nrows, 2);

[aaronsms]

Yeap fixed it! Supposed to be G_percent(nrows, nrows, 2).

[HuidaeCho]

Please add a test script.

[wenzeslaus]

Compiling with GCC gives:

main.c: In function ‘main’:
main.c:250:5: warning: ‘row’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  250 |     G_percent(row, nrows, 2);
      |     ^~~~~~~~~~~~~~~~~~~~~~~~

[wenzeslaus]

This will also need a update/rebase/merge with the main branch because there is a new flake8 job expected which needs to be completed before the merge to main can happen.

[aaronsms]

I have fixed the compilation issues as well as rebased to the main branch.

[petrasovaa]

Results from the benchmark:

[petrasovaa]

Here is a benchmark patching multiple tiles in 16 bil raster:

@aaronsms Any idea why the memory has no effect?

[aaronsms]

@aaronsms Any idea why the memory has no effect?

The result is interesting, I should expect the 4000MB should not be worse than 300MB at the very least (is it possible to run in between 300MB and 4000MB?). The memory option allows user to choose the amount of memory to allocate to enable parallelism, but it does not always improve the performance, as long as it is not below some level of memory, where the chunk size gets too small and the threads start waiting for each other.

This begs the question: is the memory option then needed, if it turns out that even at very large files (16B), this optimal threshold of memory does not grow very large, then since the user should expect to use 200/300 MB anyway, perhaps that can be hidden from the user?

Initially, the memory option is added because the initial implementation use close to nothing memory, but to enable parallelism, we need to start using the memory, and currently we are allowing the users to choose that amount.

[petrasovaa]

Here is a benchmark on a much smaller area, looks like with memory=0 there seems to be some slow down with a lot threads.

[aaronsms]

For memory=0, it auto sets to the bare minimum required for it to work, which is the number of threads * 1 row.