Files
TDT4200/exercise3/report.md
2025-10-07 15:18:14 +02:00

75 lines
2.5 KiB
Markdown

---
title: tdt4200ex3 -- 1d wave equation mpi
date: 2025-09-22
author: fredrik robertsen
---
## theory questions
### 1)
by parallelizing the code i get quite a speed-up when running four processes.
this is as i expected, because my laptop has four cores available for parallel
processing. i have done threading previously, which also gave a speed-up for
four threads. thus it makes sense that we get a speed-up here. it means we must
have more intensive calculations than the overhead of using mpi.
here's an excerpt from `make check`:
```
./sequential
Total elapsed time: 5.115875 seconds
mpiexec -n 1 --oversubscribe ./parallel
Total elapsed time: 5.347622 seconds
mpiexec -n 4 --oversubscribe ./parallel
Total elapsed time: 1.729224 seconds
mpiexec -n 13 --oversubscribe ./parallel
Total elapsed time: 2.717839 seconds
```
assuming i have implemented timing correctly, mpi is slightly slower with only
a single process, as expected. similarly, for 13 processes we get a speed-up,
but not by as much due to the overhead of having more processes that are not
necessarily capable of running in parallel -- they are limited by my hardware.
### 2)
this is a ring-buffer (halo) topology 3-stencil. a process only communicates
with its nearest neighbor. the calculations are a form of finite differences.
### 3)
_well-spoken [AI](https://kagi.com) answer:_
**point-to-point communication:**
- communication between **exactly two processes** (sender ↔ receiver)
- examples: `mpi_send`, `mpi_recv`, `mpi_sendrecv`
**collective communication:**
- communication involving **all processes** in a communicator
- examples: `mpi_bcast`, `mpi_reduce`, `mpi_allreduce`, `mpi_gather`, `mpi_scatter`
**key differences:**
| aspect | point-to-point | collective |
| ------------------- | -------------- | ---------------- |
| **participants** | 2 processes | all processes |
| **synchronization** | optional | required |
| **optimization** | manual | automatic |
| **flexibility** | high | limited patterns |
### 4)
`int* a, b` is a classic c pitfall. my auto-formatter is configured to correctly
format such a string to `int *a, b`, since pointers are a part of the variable
name definition, not the type. as such, `b` is merely an `int`.
this is slightly relevant for the entertaining c-ism `buffer[0] == 0[buffer]`
(this relates to the fact that indexing brackets are syntactic sugar for pointer
addition, which is commutative).