Differenza tra Benchmarking e Profiling

Question

Vedo il software termini analisi comparativa e profilatura usato a volte in modo intercambiabile ma per quanto riguarda la mia comprensione va c'è una differenza sottile.

Entrambi sono collegati dal tempo. Ma mentre il benchmarking riguarda principalmente la determinazione di un determinato punteggio di velocità che può essere confrontato con altre applicazioni, la profilazione fornisce informazioni esatte su dove la vostra applicazione trascorre la maggior parte del suo tempo (o numero di cicli).

Per me è sempre stato come: il test di integrazione è la contropartita del benchmarking e dell'unità test della controparte della profilazione. Ma come si inserisce il micro-benchmarking in questo?

Qualcuno ha dichiarato here:

Profiling e l'analisi comparativa sono lati rovescio della stessa medaglia, profiling aiuta a restringere il campo dove l'ottimizzazione sarebbe più utile, il benchmarking consente di isolare facilmente le ottimizzazioni e cross-confrontano loro.

Un altro disse here su Profiling:

Profiling significa cose diverse in tempi diversi. A volte significa misurare le prestazioni. A volte significa diagnosticare perdite di memoria. A volte significa ottenere visibilità in multi-threading o altre attività di basso livello.

Quindi, queste tecniche sono concettualmente diverse o semplicemente non sono in bianco e nero?

Answer 1

Un punto di riferimento è qualcosa che misura il tempo per tutta l'operazione. per esempio. Operazioni di I/O al secondo con carico di lavoro. Quindi il risultato è in genere un numero singolo, in secondi o operazioni al secondo. O un set di dati con risultati per diversi parametri, in modo da poterlo rappresentare graficamente.

È possibile utilizzare un benchmark per confrontare lo stesso software su hardware diverso o versioni diverse di altri software con cui il benchmark interagisce. per esempio. connessioni max di benchmark al secondo con diverse impostazioni di apache.

---

La creazione di profili non mira al confronto di cose diverse: riguarda la comprensione del comportamento di un programma. Un risultato del profilo può essere un intervallo di tempo impiegato per la funzione o even per instruction with a sampling profiler. Si può dire che è un profilo non un punto di riferimento perché non ha senso dire "quella funzione ha richiesto meno tempo in modo che manterremo quella e smetteremo di usare il resto".

Leggi l'articolo di Wikipedia per saperne di più: https://en.wikipedia.org/wiki/Profiling_(computer_programming)

Si utilizza un profilo per capire dove per ottimizzare. Un aumento del 10% in una funzione in cui il tuo programma spende il 99% del suo tempo è più prezioso di un aumento della velocità del 100% in qualsiasi altra funzione. Ancora meglio è quando puoi migliorare il tuo design di alto livello in modo che la funzione costosa venga chiamata meno, oltre a renderla più veloce.

---

Microbenchmarking è una forma specifica di benchmarking. Significa che stai testando una cosa super-specifica per misurare solo questo in isolamento, non la prestazione complessiva di tutto ciò che è veramente utile.

risultati Esempio: microbenchmark

• Intel Haswell's L1 cache load-use latency is 4 cycles.
• Questa versione di memcpy raggiunge l'80% del throughput dell'altra versione.

• mov eax, ecx has 0c latency on Haswell, but mov ecx, ecx has 1c latency. (L'eliminazione del movimento funziona solo tra registri diversi su Intel). Vedi quel link per la sorgente full asm di un eseguibile statico, e il contatore delle prestazioni risulta eseguendolo con un paio di corpi di loop diversi per dimostrare l'eliminazione del movimento.

  L'utilizzo dei contatori delle prestazioni della CPU per misurare il funzionamento di un micro-benchmark è un buon modo per fare esperimenti per scoprire come le CPU lavorano internamente. Vedi How exactly do partial registers on Haswell/Skylake perform? Writing AL seems to have a false dependency on RAX, and AH is inconsistent per altri esempi. In tal caso, stai definendo il tuo micro-benchmark per capire cosa lo fa girare a quella velocità. (Spesso sei più interessato ai contatori di perfezioni come uops_executed che al tempo reale o al conteggio del ciclo di clock, ad esempio per testare la micro-fusione/non-laminazione senza dover creare un ciclo in cui ciò influenzi effettivamente i cicli per iterazione.)

esemplificativo e non micro risultati dei benchmark:

• comprimere questa collezione 100MB di file ha preso 23 secondi con 7-zip (con opzioni specifiche e hardware).
• la compilazione di un kernel Linux ha impiegato 99 secondi su una combinazione hardware/software.

Vedere anche https://en.wikipedia.org/wiki/Benchmark_(computing)#Types_of_benchmarks.

Micro-benchmarking è un caso speciale di benchmarking. Se lo fai bene, ti dice quali operazioni sono costose e quali sono a buon mercato, il che ti aiuta mentre cerchi di ottimizzare. Se lo fai male, probabilmente non hai nemmeno misurato quello che hai deciso di misurare. per esempio. hai scritto qualche C per testare loops vs. while loop, ma il compilatore ha creato un codice diverso per ragioni diverse, ei tuoi risultati sono privi di significato. (Diversi modi di esprimere la stessa logica non hanno quasi mai importanza con i moderni compilatori di ottimizzazione, non perdere tempo in questo.) Il micro-benchmarking è difficile.

L'altro modo per dire che è un micro-benchmark è che di solito è necessario controllare l'output asm del compilatore per assicurarsi che stia testando ciò che si desidera testare. (per esempio che non ha ottimizzato le iterazioni del ciclo di ripetizione 10M sollevando qualcosa di costoso dal ciclo che dovrebbe ripetere l'intera operazione abbastanza volte per fornire una durata che può essere misurata con precisione.)

Micro -benchmarking può distorcere le cose, perché mettono alla prova la vostra funzione con cache calde e predizione delle diramazioni innescato, e non corrono alcun altro codice tra le chiamate del codice in prova. Questo può far sembrare buono lo svolgimento di enormi loop, quando come parte di un programma reale porterebbe a più errori di cache. Allo stesso modo, rende le grandi tabelle di ricerca un bell'aspetto, perché l'intera tabella di ricerca finisce nella cache. Il programma completo di solito sporca abbastanza cache tra le chiamate alla funzione che la tabella di ricerca non sempre colpito nella cache, in modo che sarebbe stato più conveniente solo per calcolare qualcosa. (La maggior parte dei programmi ha limiti di memoria.)

Answer 2

Un punto di riferimento può aiutare a osservare il comportamento del sistema sotto carico, determinare la capacità del sistema, imparare quali cambiamenti sono importanti, o vedere come la vostra applicazione esegue con dati diversi.

Il profilo è il mezzo principale per misurare e analizzare il punto in cui viene consumato il tempo . La profilazione prevede due passaggi: la misurazione delle attività e il tempo trascorso e l'aggregazione e l'ordinamento dei risultati in modo che l'importante attività bolla in alto. - High performance MySQL

Quello che ho capito è: riferimento è misura di conoscere la vostra applicazione, mentre profiling è misura per migliorare la vostra applicazione.

Answer 3

Spesso le persone eseguono il profiling per non misurare la velocità di un programma, ma per scoprire come ottenerlo Più veloce.

Spesso lo fanno partendo dal presupposto che la lentezza è meglio trovata misurando il tempo trascorso da particolari funzioni o righe di codice.

C'è un modo chiaro per pensare a questo: Se una funzione o una riga di codice mostra una cento inclusiva di tempo, cioè la frazione di tempo che sarebbe salvato se la funzione o la riga di codice potrebbe essere fatto prendere tempo zero (non eseguendolo o passandolo a un processore infinitamente veloce).

ci sono altre cose oltre a funzioni o righe di codice che può richiedere tempo. Quelli sono descrizioni di ciò che sta facendo il programma, ma non sono le uniche descrizioni.

Supponiamo di eseguire un profiler che, ogni N secondi di tempo effettivo (non solo il tempo della CPU) raccoglie un campione dello stato del programma, incluso lo stack di chiamate e le variabili di dati. Lo stack di chiamate è più di una pila di nomi di funzione - si tratta di una pila di siti di chiamata in cui tali funzioni sono chiamate, e spesso i valori degli argomenti. Supponiamo quindi di poter esaminare e descrivere ciascuno di questi.

Per esempio, le descrizioni di un campione potrebbe essere:

• routine X è in fase di allocazione di memoria al fine di inizializzazione di un dizionario utilizzato per la registrazione dei pazienti da Q di routine, quando una cosa del genere si rende necessario .

• Il programma è in fase di lettura di un file dll allo scopo di estrarre una risorsa stringa che, diversi livelli sopra lo stack di chiamate, verrà utilizzata per compilare un campo di testo in una barra di avanzamento esistente per indicare al utente perché il programma impiega così tanto :)

• Il programma chiama la funzione F con determinati argomenti e lo ha richiamato in precedenza con gli stessi argomenti, dando lo stesso risultato. Questo suggerisce che si potrebbe solo ricordare il risultato precedente.

• Il programma si chiama la funzione G, che è in procinto di chiamare la funzione H solo per decifrare flag di opzione tesi di G. Il programmatore sa che quelle bandiere sono sempre le stesse, suggerendo che una versione speciale di G avrebbe salvato quella volta.

• ecc ecc

Quelli sono possibili descrizioni. Se rappresentano la percentuale F di tempo, è la probabilità che ciascun campione soddisfi tale descrizione. Le descrizioni più semplici sono:

• Routine o riga di codice X viene visualizzata su Q percento dei campioni di stack. Questo è misurato compresa per cento.
• La routine D appare immediatamente sopra la routine E su R percento dei campioni di stack. Tale numero potrebbe essere inserito nell'arco di un grafico di chiamata da D a E.
• Sequenza sequenza stack-> A-> B-> C-> D-> E è la sequenza che appare sul maggior numero di campioni. Questo è il "percorso caldo".
• La routine che appare più spesso nella parte inferiore degli stack è T. Questo è il "punto caldo".

La maggior parte degli strumenti del profiler fornisce solo queste semplici descrizioni. Alcuni programmatori comprendono il valore dell'esame degli stessi campioni, in modo che possano fare più descrizioni semantiche del motivo per cui il programma sta spendendo il suo tempo. Se l'obiettivo fosse misurare con precisione la percentuale di tempo dovuta a una particolare descrizione, allora si dovrebbe esaminare un numero elevato di campioni. Ma se una descrizione appare su una grande frazione di un numero piccola di campioni, uno non ha misurato con precisione, ma sa è grande, ed è stato trovato precisione. Vedi la differenza? È possibile scambiare l'accuratezza della misurazione per la potenza del rilevamento della velocità.

Questo è il principio alla base di random pausing e la giustificazione statistica è here.