Markus Metz wrote:
> > Following r.cost @ 100%, I have changed cseg_open(16, 16, 8) to 256,256,64
> > locally.
>
> FWIW, I found that r.watershed.seg is fastest with the equivalent of
> cseg_open(200, 200, <variable number of open segments>). It seems
> logical to use powers of 2, but 200, 200 is in r.watershed.seg faster
> than 128, 128 and 256, 256.
Using powers of two only provides a benefit if the code actually takes
account of this restriction; the segment library doesn't:
int segment_address(const SEGMENT * SEG, int row, int col, int *n, int
*index)
{
*n = row / SEG->srows * SEG->spr + col / SEG->scols;
*index = (row % SEG->srows * SEG->scols + col % SEG->scols) *
SEG->len;
OTOH, r.proj uses a fixed 64x64 block size, and the "get" operation is
a macro. Other sizes would work, but there is an efficiency gain for
fixing the size at compile time.
But, if the nature of the algorithm is such that processing time
becomes a problem long before memory does, then there's no point to
using any form of segmentation.
--
Glynn Clements <[email protected]>
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
