Posso utilizzare metodi statistici per confrontare i dati delle prestazioni del benchmark?

Se esegui una serie di test con dimensioni di input simili, dovresti calcolare il tempo medio e la deviazione standard (che è la misura statistica della sicurezza che potresti avere in media).

Quando esegui test molto eterogenei, ad es. Codice sorgente di dimensioni molto diverse, si potrebbe prendere in considerazione la possibilità di calcolare la media sul tempo totale della suite di test, invece di lavorare con un tempo medio per lo slot per i casi di test differenti.

Se non stai testando le prestazioni di accesso al disco, potresti escludere la prima esecuzione per evitare distorsioni a causa della memorizzazione nella cache del sistema operativo (specialmente perché la primissima esecuzione (che sia vecchia o nuova) sopporterà il costo dell'assenza di cache)

Infine, per fare una dichiarazione generale sulle prestazioni, dovresti assicurarti che il tuo caso di test sia rappresentativo della diversità della vita reale. In caso contrario, specifica con precisione l'ambito delle tue misure (il tuo venditore farà comunque la generalizzazione per te ;-))

Problema nella generalizzazione dei risultati del benchmarking

Innanzitutto, se esegui un programma di benchmark, qualsiasi prestazione che osservi eseguendo quel programma di benchmark è probabilmente applicabile solo al tuo programma di benchmark.

Programmi di benchmark standardizzati

Per confrontare le prestazioni degli output del compilatore (per fare un reclamo sul merito del compilatore), probabilmente dovrai eseguire molti diversi tipi di programmi di benchmark. Per evitare qualsiasi gioco di prestigio statistico, questi programmi di riferimento devono provenire da un codice sorgente standardizzato, oppure devono essere implementazioni ben note di algoritmi noti.

Alcuni esempi:

• Benchmark_ (computing) - Standard di settore (verificato e verificabile)
• SPEC
• SPECint

Devi fare del tuo meglio per controllare ogni possibile influenza ambientale sul tempo di esecuzione del programma. In altre parole, qualsiasi influenza che non sia dovuta a differenze nel codice macchina generato emesso dalle tue due versioni di compilatori, devi provare a neutralizzarlo.

CPU

Un esempio di tale interferenza è la variazione di frequenza propria della CPU. Sui moderni microprocessori Intel, è necessario disabilitare SpeedStep e Opzioni Turbo Boost . È inoltre necessario modificare le impostazioni di risparmio energetico per ridurre al minimo le fluttuazioni della velocità di esecuzione della CPU. La CPU stessa dovrebbe avere una dissipazione termica più che sufficiente per prevenire la limitazione termica.

Memoria e cache

Dovresti familiarizzare con gli effetti delle prestazioni dei modelli di accesso alla memoria e della cache. Potresti essere interessato a riportare i risultati della cache a freddo, i risultati della cache a caldo o entrambi; sarà necessario applicare una preparazione adeguata prima e durante i benchmark. Questo è un argomento profondo che richiederà la definizione di una metodologia di benchmarking. Questa metodologia deve essere spiegata in ogni dettaglio al pubblico in modo che possano tentare di replicare e verificare i risultati e le attestazioni.

Sistema operativo, altri processi, memoria virtuale

Riduci al minimo il numero di altri processi o applicazioni del sistema operativo non essenziali durante il benchmark.

La velocità di esecuzione di un programma può essere soggetta all'influenza del sistema operativo, che può essere difficile da controllare. Qualunque sia il tuo tentativo, documentalo nella metodologia di benchmarking mentre segnali i risultati.

I moderni sistemi operativi utilizzano in genere over-commit, il che significa che la richiesta di un programma per più memoria può essere concessa senza effettivamente rendere questi spazio di memoria fisica pronto per l'uso. Invece, la memoria è pronta solo quando il programma raggiunge per la prima volta l'intervallo di indirizzi. Potresti voler confrontare diversi scenari rispetto alla memoria virtuale, proprio come con gli effetti della cache della CPU.

La velocità di esecuzione dipende dai dati di input di un programma?

Dipende. Nella maggior parte dei casi, supponiamo che lo faccia.

Si è tentati di supporre che un programma che applica una semplice operazione a una vasta serie di valori primitivi avrebbe una velocità di esecuzione che non dipende dal contenuto dell'array. Non fare questa ipotesi.

Rapporti sugli intervalli di confidenza

Segnala gli intervalli di confidenza come percentili molto bassi e molto alti. Ad esempio, 5% percentile e 95% percentile.

Non dare per scontato che la distribuzione di misurazione sottostante sia gaussiana.

Comprendi che ci saranno dei valori anomali; ma non respingere arbitrariamente le cose come valori anomali - potrebbero essere eventi rari che influenzano le prestazioni di esecuzione in generale (nel senso che gli utenti che eseguono i programmi di riferimento avranno una probabilità di vedere anche questi eventi rari). Questo è il motivo per cui è importante utilizzare percentili di fiducia: indica alle persone esattamente quale frazione di valori anomali si sta rifiutando. Gli utenti che necessitano di controlli più rigorosi su valori anomali possono richiedere di segnalare percentili più rigidi, ad esempio il 99,5% percentile o addirittura il 99,99% percentile.

Se usi ipotesi Gaussiane, come riassumere i risultati come media e varianza, stai distruggendo la parte delle informazioni statistiche necessarie per tener conto dei valori anomali.