In cluster la legge di Amdahl , La legge di Gustafson esiste.
Tuttavia, potrebbe esserci qualche legge che stabilisce la relazione tra CPU Hz e velocità di rete: velocità massima della rete dopo la quale nessun Mbps aggiuntivo aumenterebbe i calcoli. Esistono tali limiti e da cosa dipende?
Per un algoritmo con pochissima comunicazione tra computer (non sensibile ai limiti di larghezza di banda) che utilizza la comunicazione asincrona (non sensibile alla latenza di rete), il numero di CPU dominerà le prestazioni e il networking è per lo più irrilevante.
Per un algoritmo con alta comunicazione tra computer (molto sensibile ai limiti di larghezza di banda) che utilizza la comunicazione sincrona (molto sensibile alla latenza di rete), il numero di CPU non avrà molta importanza.
In pratica, tutti gli algoritmi si adattano tra questi estremi da qualche parte.
La legge di Amdahl si applica a questi algoritmi. Dice (parafrasato come sono pigro) "il tempo totale è il tempo impiegato per la parte che non può essere eseguita in parallelo, più la parte che può essere fatta in parallelo divisa per il numero di CPU". Questo ignora tutti i ritardi di rete / comunicazione.
Sarebbe banale modificare la legge di Amdahl per tenere conto dei ritardi di rete / comunicazione. Ad esempio: "il tempo totale è il tempo impiegato per la parte che non può essere eseguita in parallelo, più i ritardi di rete (che dicono alle altre CPU cosa fare), più la parte che può essere fatta in parallelo divisa per il numero di CPU , oltre a ritardi di rete (ottenere risultati da altre CPU) ". Tuttavia, tieni presente che questo esempio funziona solo per un determinato stile di rete (richiesta e risposta) e non funzionerà per altri casi (ad esempio se il lavoro è pipeline).
Il problema è che in genere il software non è un algoritmo: il software è una raccolta di molti algoritmi. La "legge modificata di Amdahl" finisce per essere troppo complessa (poiché diverse cose possono sovrapporsi a ritardi di comunicazione / rete, diversi stili di comunicazione possono essere utilizzati per pezzi diversi, dipende dalla tempistica, larghezza di banda e latenza, ecc.)
Alla fine della giornata; è più pratico scrivere un prototipo / simulazione e misurare il comportamento effettivo (trovare i colli di bottiglia e migliorare / scambiare gli algoritmi, finché non si riesce a trovare un modo per migliorarlo ulteriormente e rinunciare e affermare di aver trovato una risposta). / p>
Mbps non è l'unica misura per misurare la velocità della rete, l'altra discutibile più importante è il tempo di installazione (quanto tempo ci vuole perché una coppia di CPU sia pronta per inviare un pacchetto) che è in molti casi un ordine di grandezza più ampia della larghezza di banda diretta.
Questo è il motivo per cui la maggior parte degli algoritmi tenta di ridurre il più possibile l'invio
Ciò significa che non appena le dimensioni del pacchetto moltiplicano l'ampiezza di banda rispetto al tempo di configurazione, non importa quanto sia veloce la rete.
La topografia della rete e il posizionamento delle varie informazioni da calcolare sono molto importanti per la velocità con cui può avvenire l'invio (poiché ogni pacchetto blocca il percorso su cui viaggia, a meno che non venga utilizzato un metodo store and forward).
Dovrò spostare il mio corso di programmazione parallelo per dare più informazioni su questo se vuoi.
Leggi altre domande sui tag parallel-programming cluster