My name is Domenico Commisso, and I am currently a Computer Science student at the University of Pisa. I am interested in participating in GSoC 2026.
While going through the GRASS idea page, I found the “Parallelization of existing tools” project which aligns perfectly with my skills.
Although this would be my first experience contributing to open-source and GRASS GIS, I have solid experience in C, C++, and OpenMP. Recently, for a university project, I developed a parallel compressor achieving a 15x speedup on a 32-core cluster using OpenMP and thread pools.
I would appreciate your guidance on how to get started with the codebase and which modules might be the best candidates to start profiling for optimization.
Welcome! I updated the ideas list, so check the parallelization one, there is a list of tools and tasks you can try to implement.
You can also start with fixing code defects to get familiar with the code base.
I am Vinay, a 3rd-year CS student with a strong focus on Systems Programming and High-Performance Computing.
I am writing to express my interest in the “Parallelization of existing tools” project. My background is in C++ and low-level systems , am an aspiring HFT engineer, so the challenge of optimizing geospatial algorithms for latency and concurrency using OpenMP is very appealing to me.
I am new to the GRASS codebase but I am currently setting up the build environment on my local machine (WSL/Ubuntu) to familiarize myself with the core lib/gis structure.
I want to start by profiling a single module to understand the current bottleneck before attempting any parallelization. Could you point me to a specific raster module (besides the ones already listed in the ideas page) that would be a good candidate for a “first attempt” at OpenMP integration?
Following up on my previous post—I decided to dive into the codebase to get familiar with the build system and profiling tools.
I started profiling r.surf.fractal and identified that the data_reset function was a significant bottleneck, consuming ~65% of execution time due to a manual initialization loop. I have optimized it using memset, verified the mathematical correctness with r.univar, and submitted a PR.
Profiling r.grow.distance: Findings on Parallel Overhead
Hi everyone,
Following up on my work with r.surf.fractal, I decided to profile r.grow.distance to see if it was a good candidate for similar OpenMP optimization.
I wanted to share my findings because they were quite different from my previous experience.
The Experiment that I attempted to parallelize the inner loops of the distance transform. To ensure I wasn’t just measuring overhead, I tested against the Geodesic metric (which is computationally heavy) to give the threads enough work to justify the parallelization cost.
The Results (Ryzen 5600H, 12 Threads)
Serial Baseline: ~2.96s
Parallel (4 Threads): ~3.20s (Slower)
The Conclusion: It appears r.grow.distance hits a “Fork-Join Overhead” bottleneck. Because the algorithm has a strict row-by-row dependency, OpenMP has to spawn and join threads for every single row. My benchmarks show that this overhead outweighs the gains from parallelizing the math, even for heavy calculations.
Given that naive parallelization doesn’t seem effective for this specific module, I wanted to ask for your guidance:
Should I look into more complex restructuring (like blocking/tiling) for this module?
Or would it be more valuable for GSoC if I shifted my focus to other raster modules that don’t have these recursive dependencies (e.g., r.univar or r.neighbors)?
I am eager to apply these profiling skills to whichever part of the codebase needs it most!
Thanks for looking into it. I am not surprised you are getting these results. Also, you may want to test with larger datasets. One thing you could do is to look at the other parallelized tools like r.neighbors, they have benchmarks in documentation. See if you can evaluate the current implementation and perhaps suggest an improvement.
Thanks for reviewing this! It is reassuring to hear that the results are expected given the algorithm’s dependencies.
I did test with larger datasets, but the fork-join overhead remained the dominant factor. Based on this, I have decided to pivot my GSoC focus to r.resamp.stats (where I achieved a 3x speedup—see my other post) and other modules that map better to OpenMP.
I will definitely check r.neighbors as you suggested. I’ll use it as a reference implementation for parallel patterns and investigate if it has room for further optimization to be included in my proposal.