[GRASS-dev] [GRASS GIS] #3104: Parallelize tools like r.cost

[GRASS GIS]

#3104: Parallelize tools like r.cost
--------------------------+-------------------------
  Reporter:  belg4mit     |      Owner:  grass-dev@…
      Type:  enhancement  |     Status:  new
  Priority:  normal       |  Milestone:  7.3.0
 Component:  Raster       |    Version:  unspecified
Resolution:               |   Keywords:  r.cost
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+-------------------------

Comment (by mmetz):

 Replying to [comment:5 belg4mit]:
 > I understand your point, but that's still a form of iteration, simply
 over a continuously updated list rather than pixel indices (which does
 occur as well). Regardless, why couldn't the start cells be divided up
 among multiple threads? e.g; those on the top of the image for core0, and
 those on bottom for core1.

 The list needs to be updated using the cell with the current lowest cost.
 There is always only one such cell, processing the e.g. four cells with
 the lowest costs in separate threads would corrupt the result (after one
 cell is processed, the list of the smallest four cells might change). In
 other words, the order of iteration is not predictable.

 You could start a separate thread for each start point separately, but
 then you would need to create an individual temporary output for each
 start cell and process all cells once for each start cell. At the end, the
 different outputs would need to be merged, assigning to each cell the cost
 and the path to the closest start cell. In the current single-thread
 version, all start cells are loaded at the beginning and processed
 together. Each cell needs to be processed only once, regardless of the
 number of start cells. Thus with your suggestion, more cores could be
 used, but total processing time would be longer.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3104#comment:6>
GRASS GIS <https://grass.osgeo.org>