Quali sono le ragioni delle grandi differenze di prestazioni che eseguono lo stesso programma?

Questo ha molto a che fare con il sistema operativo, gli altri processi in esecuzione e la quantità di memoria utilizzata. Il sistema operativo lascerà che ogni processo abbia un certo numero di cicli della CPU prima di passare al processo successivo. Se ci sono molti altri processi, sarà più lungo tra ogni volta che il tuo programma accederà alla CPU. Inoltre, poiché il tuo programma contiene molti dati in memoria, quando la CPU passa a un processo diverso, questi dati potrebbero dover essere spostati dalla memoria. Ciò richiederà che venga temporaneamente scritto sul disco che è un processo lento (relativo ad altre operazioni in un computer).

Fondamentalmente ci sono molti fattori che possono causare la differenza nel tempo. Tuttavia, nella maggior parte dei sistemi, è possibile impostare l'esecuzione del programma con maggiore importanza rispetto ad altri processi. Questo sarà diverso in base al sistema operativo in esecuzione. Ciò potrebbe aiutare a velocizzare il tempo di esecuzione perché al tuo programma verrà assegnata una priorità più alta per eseguire altri processi.

First, and maybe not so surprisingly, I found great performance differences when running the same code on two different machines (up to 6 x faster on one machine).

Then however and very much to my own surprise, running the exactly same code on the same machine on two different days showed great performance differences.

La misurazione delle prestazioni è un argomento sorprendentemente difficile e differenze enormi come quelle che hai osservato sono molto comuni. Ci sono molti pregiudizi di misurazione noti come:

1. Il rumore del sistema operativo, come suggerito dalla risposta di DFord
2. Politiche del sistema operativo (come scheduler, memory mapper e IO-cache)
3. Variabili d'ambiente, anche non utilizzate
4. Allineamento memoria
5. Localizzazione memoria

Ciascuno di questi parametri può influenzare notevolmente le prestazioni del tuo programma. Se vuoi preparare il tuo programma "ad alte prestazioni", allora:

1. Definisci strategie per disinfettare l'ambiente in modo da ottenere il controllo sui parametri 1-5 sopra.

2. Definisci test per determinare quale combinazione di parametri fa bene.

Il punto chiave qui è che gli esperimenti devono essere riproducibili. Se non sei in grado di riprodurre un esperimento, allora include una fonte di casualità di cui hai bisogno per capire. E prima di tutto, se non riesci a riprodurre un esperimento, i risultati degli esperimenti sono random e probabilmente non vuoi prendere decisioni basate su valori casuali , vero?

Anche se questa non è la domanda che hai posto, suppongo che tu sia interessato alla misurazione delle prestazioni. Ecco alcuni riferimenti che ti suggerisco:

link

Boehm commenta la velocità di esecuzione per lo stesso binario    che varia di un fattore di 2 a seconda sul posizionamento della cache

link

Produzione di dati errati senza fare nulla Ovviamente sbagliato!   È molto facile da leggere, contiene risultati sorprendenti e dà molto   buona sensazione della difficoltà di misurazione delle prestazioni e alcuni   metodi per produrre (più) risultati affidabili.

link

"Lo stabilizzatore è un sistema di compilazione e runtime che abilita statisticamente   rigorosa valutazione delle prestazioni. "Esiste una pubblicazione scientifica   sostenendo di dimostrare che -O3 e -O2 in gcc non sono distinguibili,   troverai molti riferimenti interessanti in là.

Come ultima parola, hai appena scoperto con le tue misure che l'orologio da parete non fornisce informazioni utili quando si tratta di misurare le prestazioni dei programmi, in modo da non ottenere mai una risposta utile a una domanda come "quanto tempo corre il mio programma? "e devi considerare affermazioni più precise.

I cambiamenti radicali, inspiegabili e apparentemente casuali nei tempi di esecuzione sono una conseguenza della natura caotica di tali sistemi complessi. e con sistemi complessi, mi spingo a includere BUGS come parte della complessità. Potresti incappare in un bug importante da qualche parte nei tuoi programmi, un bug che si manifesta solo in determinate situazioni e rallenta il tuo programma apparentemente in modo casuale (finché non lo scopri)

vedi questo bug nel server SQL per un esempio di rintracciamento.

link

quindi, il punto è che aggiungi più processori, i tuoi programmi si rallentano. fino a quando non isolerai e correggi questo bug, un bug nel server SQL stesso.

L'utilizzo di due macchine diverse per confrontare un programma è fuori questione. Ci sono così tanti fattori che influenzano i risultati (hardware diverso, software diverso, cache, altri processi in esecuzione, ecc.) Che ciò che ottieni non ha valore.

Quando si utilizza la stessa macchina, è possibile fare alcune cose per rendere i risultati più affidabili. Alcuni esempi: (1) Riavvia sempre prima di iniziare un nuovo benchmark. È l'unico modo per garantire che tutte le cache siano fredde. (2) Esegui lo stesso benchmark più volte (ad esempio almeno cinque) e media i risultati invece di fare affidamento su una singola esecuzione. (3) Considerare di passare alla modalità utente singolo o di interrompere tutti gli altri programmi / servizi in esecuzione (a meno che non siano assolutamente necessari), poiché potrebbero influire sui tempi di esecuzione del programma.

Se vuoi sapere di più su quanto sia un vero e proprio benchmarking raccomando uno studio di nove anni di Benchmarking di file system e archiviazione