r.mapcalc: Support parallel computing by OpenMP

[cyliang368]

This PR parallelizes a part of the r.mapcalc module using OpenMP. Note that raster3d is still not parallelized yet.

• add note and benchmark to documentation
• add openmp to CMakeLists.txt

[petrasovaa]

NOTE: this is not valid benchmark beyond 4 cores, see the one below

I ran a benchmark on my desktop and it looks very good! I compared different data size and complexity of expression:

My machine info:

Architecture:             x86_64
  CPU op-mode(s):         32-bit, 64-bit
  Address sizes:          46 bits physical, 48 bits virtual
  Byte Order:             Little Endian
CPU(s):                   28
  On-line CPU(s) list:    0-27
Vendor ID:                GenuineIntel
  Model name:             Intel(R) Core(TM) i9-10940X CPU @ 3.30GHz
    CPU family:           6
    Model:                85
    Thread(s) per core:   2
    Core(s) per socket:   14
    Socket(s):            1
    Stepping:             7
    CPU(s) scaling MHz:   33%
    CPU max MHz:          4800.0000
    CPU min MHz:          1200.0000

Overall I don't see any slow down with more cores as @cyliang368 showed me before, so it may behave differently on different machines. I will do more testing but this looks very promising!

To clarify the plots, 'simple' means A+B, complex is (A + B - 2 * B + A * B - A / B) / 2 and neighbors is if ((A[5, 5] + B[-5, -5]) > 0, 1.6, 0.1). So the complexity of the expression makes a big difference and given there are often even larger expressions, this has potential to be even more useful.

[echoix]

So, in the tests you ran, there's not much benefit after 4 cores. Does it apply to everything, or just the expressions tested?

[petrasovaa]

So, in the tests you ran, there's not much benefit after 4 cores. Does it apply to everything, or just the expressions tested?

I suspect much larger data and more complex expression (like with eval function), we would see benefit with couple more cores. But most parallel tools in GRASS in my experience behave like that.

[cyliang368]

This reminds me of a similar behavior I observed while running benchmarks for v.surf.rst and r.texture on my laptop last year. I believe my laptop is not powerful enough, so more overheads occur when more cores are used.

Overall, I think the benchmarks from @petrasovaa 's machine look good. I will add notes and these benchmarks to the document when I have time.

[petrasovaa]

So I needed to run new benchmarks because I missed the fact that the code was already constrained to 4 cores max... So I removed locally the restriction and luckily the new results are not that much different:

Based on this I would suggest to not constrain it, there may be some slow down for simple expressions, but it doesn't look that significant. Also, the more complex expression was able to take advantage of more than 4 cores.

[petrasovaa]

Hm, I meant to test it on my fork, but apparently pushed it here...

[petrasovaa]

It looks like test_nmedian_bug_3296.py is failing on windows. One test is crashing and other give incorrect results.

[petrasovaa]

It looks like test_nmedian_bug_3296.py is failing on windows. One test is crashing and other give incorrect results.

My guess is, it is connected to using static variables:
https://github.com/OSGeo/grass/blob/main/lib/calc/xnmedian.c#L47

On my fork I removed the reallocation so it allocates every time and the tests are running now. If that's indeed the cause the question is how to deal with that, @HuidaeCho, @cyliang368 any idea? I assume the constant allocation would slow it down. Maybe there could be a smarter way to allocate it.

[cyliang368]

It looks like test_nmedian_bug_3296.py is failing on windows. One test is crashing and other give incorrect results.

My guess is, it is connected to using static variables: https://github.com/OSGeo/grass/blob/main/lib/calc/xnmedian.c#L47

On my fork I removed the reallocation so it allocates every time and the tests are running now. If that's indeed the cause the question is how to deal with that, @HuidaeCho, @cyliang368 any idea? I assume the constant allocation would slow it down. Maybe there could be a smarter way to allocate it.

I haven't had a good idea about this error, which only occurs on Windows, now. 😢