- každá úroveň výš nad listem zdvojnásobí počet komunikačních linek
- od 200/300 uzlů je poměrně drahá technologie a nehodí se pro větší systémy
- scheduler nezaručuje umístění jednotlivých uzlů (problém s časem komunikace)
- vs určení, ale delší queueing time
- Store and forward =
- celý se uloží na routeru,
- packet bufferuji celý v každém mezi uzlu;
- velký vliv na vzdálenost
- Wormhole =
- funguje na přepínání obvodů;
- rozbije se na menší části, rozdělen na celé síti;
- není takový vliv na vzdálenost
- 1B - 64B je v L1 = stejný výkon
- nejlepší = vleze se do L3
- snižování = bije se propustnost pamětí
- Všichni musí volat broadcast i přijímající (nesmí volat recv)
- Root určuje kdo data posílá
root musí mít všichni stejný, jinak se jedná o jiný broadcast
- bude pomalé
- složitost lineární - bude mě to trápit
- čekání na posledního
- chci posílat sobě = vyřeším flagem
MPI_REQUEST_NULL, kdy ignoruji poslání zprávy sobě
- využití více síťovek vs předtím pouze 1
- komunikace s uzly které jsou připraveny na komunikace
- závisí na implementaci a mašině
- nemá chování bariéry, root nemá jisté, že zpráva došla = zaplaví a pak jde dál
scatterv/gatherv jsou pomalejší, ale lze je použít, když nám nesedí počty/nelze dobře rozdělit- když možno, spíše použít
scatter a gather
- na zkoušku: krásný příklad na implementaci na písemku
- pomocí
Probe (vrátí jakou velikost posílá/dostává) lze implementovat tu v variantu
- má bariérové chování = nemohou skončit dřív, než všichni nezačnou posílat
- bariérové chování
- $O(p^2)$ - velmi náročná operace
- velmi záleží na bisekci
- není komunikativní = aplikuje se v lineární posloupnosti podle čísla ranků
- není bariérový (ale allreduce je)
- implementace:
- recv -> send = $O(2p)$
- reduce + bcast - $O(2 \log p)$
- nejlepší je allreduce $O(\log p)$