| | 275 | === Week 4 === |
| | 276 | |
| | 277 | '''1) What did I get done this week?''' |
| | 278 | |
| | 279 | r.mfilter (PR: https://github.com/OSGeo/grass/pull/1708) |
| | 280 | |
| | 281 | - Add test cases for different input options (Sequential/Parallel filters, repeated, null_mode) |
| | 282 | - Add parallel implementations for all options excluding Sequential filters (inherently not possible to do parallelization |
| | 283 | |
| | 284 | '''2) What do I plan on doing next week?''' |
| | 285 | |
| | 286 | Upon discussion with the mentors, we decided to change the current implementation for r.neighbor that currently uses Segment libraries that uses a temporary file buffer for the different threads to work on before producing the raster file format. We realized that the Segment library does not fit the use cases enough to compensate for the overhead it might add. It was essentially used as an API to write to the file buffer, and we are not making good use of its caching capabilities. A native temporary file buffer should fit our use cases the most where the threads can write output simultaneously (which is the current implementation for r.mfilter). |
| | 287 | |
| | 288 | Next week, I aimed to make the necessary changes for r.neighbor and do proper benchmarking on large raster files to monitor the performance gain from parallelization (r.mfilter). |
| | 289 | |
| | 290 | |
| | 291 | '''3) Am I blocked on anything?''' |
| | 292 | |
| | 293 | No, it has been good so far. |
| | 294 | |
| | 295 | |
