[GRASS-dev] GRASS GIS nightly builds

[Markus Metz]

On Mon, Feb 25, 2013 at 6:14 AM, Hamish <hamish_b at yahoo.com> wrote:
> Hi,
>
>
> for v.surf.bspline my plan was to put each of the data subregions
> in their own thread

Be aware that the order of the subregions matters right now. You will
need to rewrite lib/lidar and all modules that use the lidarlib in
order to change that and be able to put subregions into their own
threads. Be aware that disk I/O is not thread safe, you would need to
read input data for each subregion into a separate temp file with a
unique file descriptor per thread.

Markus M


; for v.surf.rst my plan was to put each of
> the quadtree squares into their own thread. Since each thread
> introduces a finite amount of time to create and destroy, the
> goal is to make fewer, longer running ones. Anything more than ~
> an order of mangnitude more that the number of cores you have is
> unneeded overhead.
>
> e.g., processing all satellite bands at the same time is a nice
> efficient win. If you process all 2000 rows of a raster map in
> 2000 just-an-instant-to-complete threads, the create/destroy
> overhead to thread survival time really takes its toll.
> Even as thread creation/destruction overheads become more
> efficiently handled by the OSs and compilers, the situation will
> still be the same. The interesting case is OpenCL, where your
> video card can run 500 GPU units..
>
>
> Hamish
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev