Diagrammi di ridimensionamento / efficienza paralleli log-log

Gran parte del mio lavoro ruota attorno al miglioramento della scalabilità degli algoritmi e uno dei modi preferiti per mostrare il ridimensionamento parallelo e / o l'efficienza parallela è quello di tracciare le prestazioni di un algoritmo / codice sul numero di core, ad es.

dove l' asse rappresenta il numero di core e l' asse un po 'metrico, ad esempio il lavoro svolto per unità di tempo. Le diverse curve mostrano efficienze parallele del 20%, 40%, 60%, 80% e 100% rispettivamente a 64 core.$x$$y$

Sfortunatamente, in molte pubblicazioni, questi risultati sono tracciati con un ridimensionamento del log-log , ad esempio i risultati in questo o in questo documento. Il problema con questi grafici di log è che è incredibilmente difficile valutare l'effettivo ridimensionamento / efficienza paralleli, ad es

Che è la stessa trama di cui sopra, ma con il ridimensionamento log-log. Si noti che ora non esiste una grande differenza tra i risultati per l'efficienza parallela del 60%, 80% o 100%. Ho scritto un po 'più ampiamente su questo qui .

Quindi, ecco la mia domanda: quali sono le motivazioni per mostrare i risultati nel ridimensionamento dei log-log? Uso regolarmente il ridimensionamento lineare per mostrare i miei risultati e vengo regolarmente martellato dagli arbitri che affermano che i miei risultati di ridimensionamento / efficienza paralleli non sembrano buoni come i risultati (log-log) degli altri, ma per la mia vita io non riesco a capire perché dovrei cambiare gli stili di trama.

Attualmente stiamo scrivendo un documento che contiene una serie di grafici comparabili e abbiamo più o meno avuto lo stesso problema. L'articolo tratta del confronto tra il ridimensionamento di diversi algoritmi e il numero di core, che varia tra 1 e fino a 100k su un BlueGene. La ragione per usare i loglog in questa situazione è il numero di ordini di grandezza coinvolti. Non è possibile tracciare 6 ordini di grandezza su una scala lineare.

E infatti, quando si traccia il tempo sul numero di core nel loglog, gli algoritmi non sono molto distinguibili, come si può vedere nella trama seguente.

$E_p=T_1/(p T_p)$$T_1$$T_p$$p$$p$$E_p$$p$

$E_p=T_{ref}/(p T_p)$$T_{ref}$ dell'algoritmo più veloce .

Tracciare l'efficienza parallela relativa su una scala di semilogrammo mostra abbastanza chiaramente il ridimensionamento di un algoritmo e mostra anche come gli algoritmi si comportano l'uno rispetto all'altro.

Georg Hager ne ha scritto in Fooling the Masses - Stunt 3: la scala di registro è il tuo amico .

Sebbene sia vero che i grafici di log-log di forte ridimensionamento non sono molto esigenti nella fascia alta, consentono di mostrare il ridimensionamento su molti più ordini di grandezza. Per capire perché questo è utile, considera un problema 3D con un perfezionamento regolare. Su una scala lineare, è possibile mostrare ragionevolmente le prestazioni su circa due ordini di grandezza, ad esempio 1024 core, 8192 core e 65536 core. È impossibile per il lettore dire dalla trama se hai eseguito qualcosa di più piccolo, e realisticamente, la trama per lo più confronta solo le due corse più grandi.

Ora supponiamo di poter adattare 1 milione di celle della griglia per core in memoria, ciò significa che dopo un forte ridimensionamento di due volte di un fattore 8, possiamo ancora avere 16k celle per core. Questa è ancora una dimensione di sottodominio considerevole e possiamo aspettarci che molti algoritmi funzionino in modo efficiente lì. Abbiamo coperto lo spettro visivo del grafico (da 1024 a 65536 core), ma non siamo nemmeno entrati nel regime in cui il forte ridimensionamento diventa difficile.

Supponiamo invece che siamo partiti da 16 core, anche con 1 milione di celle della griglia per core. Ora se scaliamo a 65536 core, avremo solo 244 celle per core, che sarà molto più esigente. Un asse log è l'unico modo per rappresentare chiaramente lo spettro da 16 core a 65536 core. Ovviamente puoi sempre usare un asse lineare e avere una didascalia che dice "i punti dati per i nuclei 16, 128 e 1024 si sovrappongono nella figura", ma ora stai usando le parole invece della figura stessa per mostrare.

Una scala log-log consente inoltre al ridimensionamento del "ripristino" di attributi della macchina come lo spostamento oltre un singolo nodo o rack. Sta a te decidere se è desiderabile o meno.

Sono d'accordo con tutto ciò che Jed ha detto nella sua risposta, ma volevo aggiungere quanto segue. Sono diventato un fan del modo in cui Martin Berzins e i suoi colleghi mostrano il ridimensionamento per la loro struttura di Uintah. Tracciano un ridimensionamento debole e forte del codice sugli assi log-log (utilizzando il tempo di esecuzione per fase del metodo). Penso che mostri come il codice si ridimensiona abbastanza bene (anche se la deviazione dal ridimensionamento perfetto è un po 'difficile da determinare). Vedi a pagina 7 e 8 le figure 7 e 8 di questo * documento per esempio. Danno anche una tabella con i numeri corrispondenti a ciascuna figura di ridimensionamento.

Un vantaggio di questo è che una volta forniti i numeri, non c'è molto che un recensore possa dire (o almeno non molto che non si può confutare).

* J. Luitjens, M. Berzins. "Miglioramento delle prestazioni di Uintah: un quadro computazionale di mesh adattivo su larga scala", in Atti del 24 ° Simposio internazionale di elaborazione parallela e distribuita IEEE (IPDPS10), Atlanta, GA, pagg. 1--10. 2010. DOI: 10.1109 / IPDPS.2010.5470437