Re: [GRASS-dev] Debugging, parallelism, etc.
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) h...@geobabble.org william.w.hargr...@usda.gov http://www.geobabble.org/~hnw ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] clean_temp.c versus deleting mapset's .tmp
This is for old GRASS codgers like me who run GRASS commands *outside* the GRASS shell, by setting all of the environment variables. This is the way that we change active mapsets as well. I do this to have all of the *nix commands integrated seamlessly with GRASS commands. If a particular GRASS command aborts or dies, the temp files in the .tmp directory are left behind. Since we never run the shell, .tmp is never deleted, and they build up, eating disk space. This thread is also germane with respect to the current discussion of GRASS environment variables. Currently I shift between GRASS 6 and 7 by sourcing an alternative .bashrc file that makes use of the strippath function to clean GRASS 6 stuff from the existing paths ... Please don't eliminate env variables or alter them too significantly ... Thanks, Bill H. On 05/21/2015 04:45 AM, Glynn Clements wrote: Vaclav Petras wrote: when I was working on grass.py I saw there usage of clean_temp function which calls clean_temp program and deletion of the whole .tmp directory and I can't make sense out of it. It seems to me that clean_temp (lib/init/clean_temp.c) executable called in grass.py is not necessary because the whole .tmp directory is anyway deleted at the beginning and at the end of the session. clean_temp is doing some special cleaning according to pids but whole directory is deleted anyway at the end. Can the whole lib/init/clean_temp.c can be safely removed? Or maybe it has some meaning when executed before the session starts because at that point .tmp is not deleted. Can someone please clarify this for me here or in the source code? Also, the clean_temp function is called manually while other cleanups are called using at exit mechanism. Supposing we need the clean up at all, I'm not sure if there is any reason to keep it explicit. Perhaps this was just inconsistency, not an intention. clean_temp is more restrictive in what it will remove (only files owned by the current user, only files older than 4 days). The original rationale for this behaviour is probably forgotten, and it's unclear if it's still valid (probably not, if the startup script is removing the entire directory at the end of the session and no-one has complained). -- 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) h...@geobabble.org http://www.geobabble.org/~hnw ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
