[GRASS-dev] Debugging, parallelism, etc.

[William Hargrove]

Can still run GRASS outside the shell by setting all of the environment 
variables appropriately ...

OpenMP just works by "unrolling" all of the determinate loops, i.e., the 
ones that iterate a fixed number of times.  No speedups to anything else.

Speedup from OpenMP will be limited, depending on the number of 
determinate loops present, and how much of the load they represent.

pthreads are totally flexible, but the programmer has to specify 
everything, very carefully ...

But pthreads can speed up lots of stuff outside of determinate loops ...


HTH,

Bill H.


On 10/9/2022 12:37 PM, Brad ReDacted wrote:
> Hello,
> 
> I'm working on adding parallelism to modules, but debugging is turning 
> out to be a logistical nightmare:
> 
> Why do I not get any reporting from GCC option '-fsanitize=address|thread"?
> 
> I am also having trouble getting the profiler to work properly inside 
> GRASS (I assume due to shell?). The gmon.out file produced has no usable 
> data.
> 
> OpenMP is extremely poorly supported by most tools. valgrind with 
> helgrind reports a lot of nonsense. I can't seem to get the Intel linux 
> tools to work properly, either.
> 
> BTW, we are supporting both pthreads and OpenMP. While this isn't an 
> issue in most cases, there can be races and deadlocks if not handled 
> properly. Pthreads aren't entirely portable. OpenMP is. However, 
> pthreads gives us a more control. May I suggest using OpenMP for most 
> modules and reserve Pthreads to libraries, etc? Or should we start 
> moving away from pthreads?
> 
> Any suggestions would be greatly appreciated!
> 
> 

-- 
William W. Hargrove
Eastern Forest Environmental Threat Assessment Center
USDA Forest Service
Southern Research Station
200 WT Weaver Boulevard
Asheville, NC  28804-3454

(828) 257-4846
(865) 235-4753 (cell)
(828) 257-4313 (fax)
hnw at geobabble.org
william.w.hargrove at usda.gov
http://www.geobabble.org/~hnw