What I worked on in week 1: I built and benchmarked two different ways to parallelize r.param.scale. The first version reads strips straight from the disk, conceptually very similar to how r.neighbors is parallelized (draft PR #7440), and the second loads them into RAM per thread (draft PR #7442). Both gave exactly the same output as the original serial code across window sizes 5 to 51. There was some speedup compared to the serial version, but not as fast as it should be. In Friday’s meeting the mentors and I agreed #7440 is conceptually the better route to take. I also benchmarked r.neighbors on my computer to make sure it wasn’t a reason I was seeing poor speedup ratios. It scaled well there at larger windows, so my code was the reason for the weaker scaling, not the machine. I ended with doing a much deeper analysis of what the differences were between my disk approach and r.neighbors. I found the main gaps to be not having the two-level band structure, each thread holding too much of the map in memory, no memory limit option, and no mask handling.
What I’m doing this week: Refactoring #7440 to make sure I cover all the gaps I mentioned above. Once I’m done I will update the draft PR and also add in benchmarking scripts I used so mentors can try replicating results from their end if they want to.
What’s blocking me: Nothing, I should be good to go.
Thanks,
Kaushik