r.neighbors: fix integer overflow

[metzm]

Fix integer overflow for regions with more than INT_MAX cells.

A very similar cast to size_t is already in r.series, but maybe other modules that were recently parallelized also need some attention.

[nilason]

Looks good to me!

[...] but maybe other modules that were recently parallelized also need some attention.

Here is a list of modules with OpenMP support:

• r.mfilter [new]
• r.neighbors [new]
• r.patch [new]
• r.proj
• r.resamp.filter [new]
• r.resamp.interp [new]
• r.series [new]
• r.series.accumulate
• r.sim
• r.slope.aspect [new]
• r.sun
• r.univar [new]
• v.surf.rst

[metzm]

Evaluation of the other modules could be worth an issue?

For r.neighbors and possibly for other modified modules, I don't see a speed improvement by a large cache for output rows. The output rows need to be written one by one and a large cache for these output rows only needs more RAM without any benefits. This cache for output rows could therefore always be reduced to the needed minimum = number of threads.

[nilason]

Evaluation of the other modules could be worth an issue?

Wouldn't hurt, at least for this "region cell no > INT_MAX" situation.

For r.neighbors and possibly for other modified modules, I don't see a speed improvement by a large cache for output rows. The output rows need to be written one by one and a large cache for these output rows only needs more RAM without any benefits. This cache for output rows could therefore always be reduced to the needed minimum = number of threads.

Benchmark suggests otherwise: https://grass.osgeo.org/grass82/manuals/r.neighbors.html

[neteler]

(will be backported in #2856)

[metzm]

For r.neighbors and possibly for other modified modules, I don't see a speed improvement by a large cache for output rows. The output rows need to be written one by one and a large cache for these output rows only needs more RAM without any benefits. This cache for output rows could therefore always be reduced to the needed minimum = number of threads.

Benchmark suggests otherwise: https://grass.osgeo.org/grass82/manuals/r.neighbors.html

No obvious improvement from 5 MB onwards? Looks like there is no benefit by caching large parts of the output.

[nilason]

For r.neighbors and possibly for other modified modules, I don't see a speed improvement by a large cache for output rows. The output rows need to be written one by one and a large cache for these output rows only needs more RAM without any benefits. This cache for output rows could therefore always be reduced to the needed minimum = number of threads.

Benchmark suggests otherwise: https://grass.osgeo.org/grass82/manuals/r.neighbors.html

No obvious improvement from 5 MB onwards? Looks like there is no benefit by caching large parts of the output.

Now I see what you mean, yes, you're quite right.

[wenzeslaus]

...This cache for output rows could therefore always be reduced to the needed minimum = number of threads. ...
No obvious improvement from 5 MB onwards?

Note that in the code memory=0 translates to minimal memory required. 5MB for the data in the benchmark means a small cache (judging from difference between 0MB and 5MB).