[GRASS-dev] Multi-threading and use of multiple processors

[Glynn Clements]

Colin Nielsen wrote:

> In my experience, the main drain in computation time is the IO not the
> actual calculation of the btree. Is there any way to parallelize the
> IO by passing rows to different cores or something like that ie. "for
> (row = 0; row < nrows; row++) {"?

That's feasible, but r.cost and r.walk aren't row-by-row algorithms.

With a row-by-row algorithm, you still have the issue that you can't
have multiple concurrent invocations of G_get_raster_row() etc on a
single map (in 6.x, you simply can't have multiple concurrent
invocations, even on different maps).

But you can have one thread which reads rows, multiple threads which
each process a particular row, and one thread which writes rows. The
number of useful intermediate threads is limited by the I/O rate.

> Or a more efficient segment library sounds good as well. Is there a
> way to estimate how much more efficient would it be

Hard to say. The main inefficiencies with the current implementation
are:

1. The tile size isn't restricted to a power of two (so it uses
division/remainder rather than shift/mask).

2. The tile size is set at run-time rather than compile-time.

3. Acess is via function calls rather than macros or inline functions.

The version in r.proj[.seg] doesn't have these issues, although it's
currently read-only.

> and would it make use of multiple cores?

Using multiple threads for segment I/O would probably be a net loss,
as you would need to perform locking for every access.

Multi-threading is most effective if you can partition the data such
that you don't need to perform locking.

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