Come posso misurare il modo in cui il mio codice multithreading scala (speedup)?

Question

Quale sarebbe il modo migliore per misurare la velocità del mio programma assumendo che abbia solo 4 core? Ovviamente potrei misurarlo fino a 4, tuttavia sarebbe bello sapere per 8, 16 e così via.

Idealmente mi piacerebbe conoscere la quantità di aumento di velocità per numero di fili, simile a questo grafico:

C'è un modo che io possa fare questo? Forse un metodo per simulare più core?

Answer 1

Non penso che ci sia un vero modo per farlo, ma una cosa che mi viene in mente è che potresti usare una macchina virtuale per simulare più core. In VirtualBox, ad esempio, è possibile selezionare fino a 16 core dal menu standard, ma sono molto fiducioso che ci siano alcuni hack, che possono rendere più di questo e altri VirtualMachines come VMware potrebbero anche supportare più out of the box.

Answer 2

non credo questo è possibile in quanto ci sono troppe variabili per essere in grado di estrapolare con precisione performace. Anche supponendo che tu sia parallelo al 100%. Ci sono altri fattori come la velocità del bus e i problemi di cache che potrebbero limitare le prestazioni, per non parlare delle prestazioni periferiche. Il modo in cui tutti questi fattori influenzano il tuo codice può essere fatto solo misurando sulla tua piattaforma hardware specifica.

Answer 3

bamboon ed e Doron sono corretti che molte variabili in gioco sono, ma se si dispone di una dimensione di ingresso sintonizzabile n, si può capire la forte ridimensionamento e debole ridimensionamento del codice.

Il forte ridimensionamento si riferisce alla risoluzione della dimensione del problema (ad esempio n = 1M) e alla variazione del numero di thread disponibili per il calcolo. Il ridimensionamento debole si riferisce alla risoluzione della dimensione del problema per thread (n = 10k/thread) e alla variazione del numero di thread disponibili per il calcolo.

È vero che ci sono un sacco di variabili al lavoro in qualsiasi programma - tuttavia se si dispone di alcune dimensioni di input di base n, è possibile ottenere una parvenza di ridimensionamento. Su un simulatore n-body ho sviluppato alcuni anni fa, ho variato i thread per le dimensioni fisse e le dimensioni di input per thread e sono stato in grado di calcolare ragionevolmente una misura approssimativa di quanto bene il codice multithreaded ridimensionato.

Poiché si dispone solo di 4 core, è possibile calcolare il ridimensionamento fino a 4 thread. Questo limita fortemente la tua capacità di vedere quanto sia scalabile per carichi ampiamente threaded. Ma questo potrebbe non essere un problema se la tua applicazione viene utilizzata solo su macchine in cui vi sono piccoli core count.

Hai davvero bisogno di pormi la domanda: sarà usato su 10, 20, 40+ thread? Se lo è, l'unico modo per determinare con precisione il ridimensionamento a quei regimi è di metterlo a punto in realtà su una piattaforma in cui l'hardware è disponibile.

---

Nota a margine: seconda dell'applicazione in uso, potrebbe non importa che hai solo 4 core. Alcuni carichi di lavoro scalano con l'aumento dei thread indipendentemente dal numero reale di core disponibili, se molti di questi thread trascorrono del tempo "in attesa" che qualcosa accada (ad esempio server Web).Se stai facendo puro calcolo, questo non è il caso

Answer 4

Mi dispiace, ma a mio parere, l'unica misurazione affidabile è quella di ottenere effettivamente un 8, 16 o più core machine e test su quella.

La saturazione della larghezza di banda della memoria, il numero di unità funzionali della CPU e altri colli di bottiglia hardware possono avere un enorme impatto sulla scalabilità. So per esperienza personale che se un programma è scalabile su 2 core e su 4 core, potrebbe rallentare notevolmente quando eseguito su 8 core, semplicemente perché non è sufficiente avere 8 core per poter scalare 8x.

Si potrebbe provare a prevedere cosa accadrà, ma ci sono un sacco di fattori che devono essere presi in considerazione:

1. cache - dimensione, numero di strati, condivise/non condiviso
2. larghezza di banda di memoria
3. numero di core rispetto al numero di processori, ad esempio è una macchina a 8 core o a due quad core
4. interconnessione tra core: un numero inferiore di core (2, 4) può ancora funzionare in modo ragionevole bene con un bus, ma per 8 o più core un'interconnessione più sofisticata è necessario
5. accesso alla memoria - di nuovo, un numero inferiore di core funziona bene con il modello SMP (multiprocessing simmetrico), mentre un numero maggiore di core richiede un modello NUMA (accesso non uniforme alla memoria).

Answer 5

Suppongo che stiate chiedendo la misurazione, quindi non affronterò il problema di prevedere l'effetto su un maggior numero di core.

Questa domanda può essere visualizzata in un altro modo: quanto impegnato è possibile mantenere ogni thread, e che cosa totalizzano fino a? Quindi, per sei thread, in esecuzione a dire il 50% di utilizzo ciascuno, significa che sono in esecuzione 3 processori equivalenti. Dividendo che, per esempio, quattro processori, significa che i tuoi metodi stanno raggiungendo il 75% di utilizzo. Confrontando tale utilizzo, rispetto al tempo di accelerazione effettivo, ti viene indicato quanto del tuo utilizzo è un nuovo sovraccarico e quanto è reale l'accelerazione. Non è quello a cui sei veramente interessato?

L'utilizzo del processore può essere calcolato in tempo reale in un paio di modi diversi. I thread possono chiedere autonomamente al sistema i tempi di thread, i rapporti di calcolo e mantenere i totali globali. Se hai il controllo totale sugli stati di blocco, non hai nemmeno bisogno delle chiamate di sistema, perché puoi semplicemente tenere traccia del rapporto tra i cicli di blocco e quelli non bloccanti, per l'utilizzo del calcolo. Un pacchetto di strumentazione multithreading in tempo reale che ho sviluppato utilizza tali metodi e funzionano bene. Il contatore della cpu in cpu più recente legge all'interno di 20 cicli di macchina.