On Mon, Feb 25, 2013 at 6:14 AM, Hamish <[email protected]> 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-dev _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
