1.9 KiB
author, date, title
| author | date | title |
|---|---|---|
| fredrik robertsen | 2025-10-07 | exercise 4 |
theory
a) gather vs. allgather
both are collective operations that attempt to "gather" or unify some
calculation result. the difference lies in that gather sends the combined
result of all processes' calculations to a single root process, while
allgather redistributes it across all other processes again.
since allgather has to do significantly more I/O in the form of communicating
between processes, it can take more time and thus be slower than a simple
gather.
d) corner communication in task 6
to communicate the rows and columns, we just have to do simple index magic to send all the correct cells to the correct neighbors. this is very tedious.
corners are spicy. you have to correctly pass your corner onto the neighbor who is ready to receive your corner, and you have to receive a corner from another neighbor who is sending you their corner. all in all, it's actually just as complicated as communicating rows and columns; you just need to get some indices right and make sure you send the data to the right place.
also, avoid a deadlock by using the correct tags in a sendrecv.
c) periodic vs. non-periodic
periodicity refers to whether or not a cartesian grid wraps around, i.e. if the edges of the grid can communicate directly with the processes on their opposite side. periodic grids enables wrapping, while non-periodics don't.
this allows for quicker communication between processes that are maximally far away from each other.
in this example, the cartesian is not periodic, since we do not need to send any data between the edges.
d) mpi i/o race conditions
with mpi i/o you use collective operations to write the calculated data to the filesystem. we can find an offset that let's us write the data into the same file in a disjoint region concurrently, avoiding race conditions.