[GRASS-dev] Interested in parallelization of GRASS

[Glynn Clements]

Markus Metz wrote:

> The segment lib implementation in trunk is considerably faster than in
> 6.x, but not as efficient as the caching method of r.proj. Some
> reasons why the segment library is slower than the caching code in
> r.proj are 1) write support in the segment lib, 2) flexible data
> storage size in the segment lib, 3) flexible tile size in the segment
> lib, 4) bad abuse of the segment library, e.g. in r.los.

The main factors for performance are whether the tile size is fixed at
compile time and whether it's known (at compile time) to be a power of
two.

It wouldn't be particularly hard to structure the r.proj tile cache
code such that the tile size can be set by the module, so long as it's
set at compile time. Allowing the tile size to be set at run time
incurs an inevitable performance penalty.

The power-of-two constraint needn't be enforced by the code. The
shifts and masks could be replaced by multiplication, division and
modulo; any modern compiler will optimise these back to shifts and
masks if the tile size is a compile-time constant which is a power of
two.

OTOH, I'm not sure there's any benefit to relaxing the requirement. 
Some modules may be less efficient if the tile size is significantly
too small or too large, but being off by a factor of sqrt(2) shouldn't
be an issue.

-- 
Glynn Clements <glynn at gclements.plus.com>