[GRASS-dev] Interested in parallelization of GRASS

Glynn Clements glynn at gclements.plus.com
Fri Apr 8 21:27:30 EDT 2011


Markus Metz wrote:

> > 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.
> 
> That means that the r.proj tile cache can not go into a library
> function because libraries are compiled before modules, i.e. tile size
> and data structure size are no known to the library at compile time,
> correct? Thus the r.proj tile cache code would need to be duplicated
> for each module, making maintenance more tedious. See e.g. the
> different versions of crs.[c|h] floating around in the imagery
> modules.

Much of the r.proj tile cache is implemented by macros in the header
file, which are compiled as part of the module. That's the part where
the optimisations matter. The I/O code in the library can have the
tile size selected at run time.

IOW, modules would do e.g.:

	#define TILE_WIDTH 64
	#define TILE_HEIGHT 64
	#include <grass/tile_cache.h>
	...
	Tile_Cache_Setup(..., TILE_WIDTH, TILE_HEIGHT);

> > 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.
> 
> The tile size used by r.cost, r.walk, r.watershed in G7 is 64x64
> throughout, as for the r.proj tile cache. That size seems to be good
> for various different region sizes. With the exception of r.watershed
> where a sorted array is stored in a segmented structure, i.e. only one
> row, many columns.

I suspect that optimal sizes for r.proj would have the width greater
than the height, on the assumption that real-would cases would
typically have relatively little rotation or curvature (i.e. 
horizontal lines in the target projection aren't far from horizontal
in the source projection).

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


More information about the grass-dev mailing list