Confronto tra i metodi di iterazione: numero di iterazioni rispetto al tempo della CPU

Sto confrontando due metodi iterativi per invertire matrici quadrate casuali. Poiché le matrici sono casuali, ogni caso di test richiede sia quantità diverse di iterazioni sia tempi diversi. La mia domanda è, oltre al tempo medio della CPU, il valore medio delle iterazioni prese da entrambi i metodi informazioni utili per confrontare i metodi.

performance benchmarking

— Srijan
fonte

Ho riformulato la tua domanda per renderla più chiara. Assicurati che non abbia cambiato il tuo significato in alcun modo.

— Godric Seer,

@GodricSeer La tua modifica ha migliorato la mia domanda. Grazie

— srijan il

Risposte:

In generale, entrambi i metodi di confronto delle prestazioni hanno il loro posto.

Confrontare il tempo della CPU è in un certo senso la metrica più interessante, perché alla fine della giornata sei davvero interessato a quale dei metodi è più veloce. (Ma assicurati che i criteri di terminazione siano comparabili; ad esempio, entrambi i metodi producono un'approssimazione con la stessa accuratezza). Lo svantaggio è che questo ti dice solo quale metodo (e, soprattutto, quale implementazione ) è più veloce sulla macchina su cui hai eseguito i test. Non vi è alcuna garanzia che una macchina diversa con diversa architettura o software scelga lo stesso vincitore.
confrontando numeri di iterazione , d'altra parte, è indipendente dalla macchina, ma potenzialmente fuorviante se i due metodi hanno iterazioni molto diverse: in questo caso il metodo con iterazioni meno costose ma più costose potrebbe non essere preferibile (ad esempio, metodi di ottimizzazione di Newton vs. gradiente per l'ottimizzazione se hai bisogno solo di una precisione molto bassa).

Quindi, sì, ha senso fornire entrambi i numeri [1], e l'ho visto spesso fatto nelle pubblicazioni. C'è anche una terza opzione:

Confronto tra numeri di operazioni elementari . Se entrambe le iterazioni consistono nello stesso tipo di operazione opportunamente costosa, ma richiedono un numero diverso (forse nemmeno lo stesso numero in ciascuna iterazione), ha senso contare il totale numero di queste operazioni. Nel tuo caso, un probabile candidato sarebbero le moltiplicazioni matrice-vettore o matrice-matrice.

[1] Statistiche sicuramente presenti su più tiri; se mostri mezzi, non dimenticare di includere anche le deviazioni standard.

— Christian Clason
fonte

Non prendere solo mezzi! Se hai abbastanza punti di prova con input casuali, traccia una distribuzione.

— Bill Barth,

@BillBarth - buon punto, anche se potrebbe non essere sempre fattibile; ma dare deviazioni standard insieme alla media dovrebbe essere sempre possibile. In effetti, quali statistiche presentare per la segnalazione delle prestazioni sembrano un'ottima domanda di follow-up.

— Christian Clason,

@BillBarth Hai fatto un buon punto. Ma sto usando diverse matrici di test in ordine crescente. Per tali casi non è possibile tracciare la distribuzione da allora devo tracciare le distribuzioni per tutte le altre matrici di test. Ecco perché volevo tabularli. Grazie per i tuoi commenti

— srijan,

@srijan: avrai i dati, dovresti tracciare istogrammi per te dove puoi. Non devi pubblicarli tutti, ma ti prometto che un grafico della distribuzione ti dirà più di un mare di numeri o solo le medie lo faranno mai.

— Bill Barth,

Includerei il tempo di esecuzione per iterazione. Poiché ogni matrice è diversa, è possibile avere un numero diverso di iterazioni con tempi di esecuzione diversi. Insieme a quanto affermato da @Cristian, i tempi di esecuzione per iterazione sarebbero utili.

— jbcolmenares,

Trovo che il numero di iterazioni sia una metrica fuorviante perché suggerisce "velocità" quando non lo è. Per un semplice esempio di confronto tra alcuni precondizionatori diversi che mostra questa differenza, vedere qui: http://www.dealii.org/developer/doxygen/deal.II/step_6.html#Possibilityforextensions

— Wolfgang Bangerth
fonte

Grazie per la risposta. Non riesco a capire che il numero di iterazioni di questa riga sia una metrica fuorviante perché suggerisce "velocità" quando non lo è ". L'esempio che mi hai suggerito è alquanto difficile per me da capire.

— srijan,

Quello che sto dicendo è che spesso presentiamo "numero di iterazioni" equivalenti a "tempo di CPU utilizzato", il che implica che un metodo che richiede meno iterazioni è anche più veloce. Ma questo non è vero, come mostrato dalle figure a cui mi sono collegato.

— Wolfgang Bangerth,

Ora ho compreso appieno il tuo punto. Lo stesso ho osservato con il metodo Newton per approssimare l'inverso di una matrice quadrata. A mano a mano che aumenta l'ordine del metodo, inizialmente diminuiscono sia il tempo della CPU sia il numero di iterazioni, ma all'aumentare dell'ordine il tempo di avvio della CPU aumenta anche se il numero di iterazioni diminuisce. Grazie mille per la tua risposta.

— srijan,

Nel caso in cui non sia chiaro nelle altre risposte, a quale numero di iterazioni sono utili gli argomenti big-O.

Non è buono per la velocità assoluta, perché ciò dipende dal tempo medio per iterazione, che può differire tra i metodi per un grande fattore.

Ad esempio, vi è la tendenza a ignorare il costo del calcolo degli indici dell'array e ciò potrebbe rappresentare una grande frazione del tempo della CPU.

AGGIUNTO: Inoltre, come ho sottolineato altrove, per ogni invocazione del metodo è generalmente previsto un costo di installazione. Quindi, se le matrici non sono in genere molto grandi, quel costo di installazione può rappresentare da solo una grande frazione del tempo della CPU (tale che rimuoverlo farebbe una grande differenza di velocità).

— Mike Dunlavey
fonte