Considerazioni progettuali sul consumo di risorse
6.3.1 La normalizzazione di GoogLeNet su PC
Ricordando che Caffe utilizza gli LRN layer per normalizzare i dati, i quali fanno uso della formula 4.2 mostrata in precedenza, visti i dati ricavati per essi con GoogLeNet su PC, si è voluto partizionare ulteriormente i tempi all’interno di un layer di questo tipo per capire quale operazioni risultassero essere onerose e causare il fenomeno visto nella figura 6.5.
Normalmente in questo capitolo sono stati omessi i dettagli implementa-tivi, ma in questo unico caso sarà fatta un’eccezione, dato che è necessario capire come si comporta il framework Caffe per comprendere i successivi grafici.
Per effettuare l’ulteriore suddivisione è stato necessario visionare e mo-dificare leggermente il file lrn_layer.cpp, all’interno del framework di Caffe inserendo anche qui delle istruzioni per misurare i tempi voluti.
Innanzitutto è bene sapere che su Caffe c’è una fase preliminare di setup in cui vengono inizializzati tutti i layer della rete, normalization layer compresi. C’è un’apposita funzione all’interno del codice di un normalization layer che fa questo: effettua in pratica un check per vedere se esistono layer nella rete di questo tipo. Quindi i tempi di setup dei due normalization layer presenti su GoogLeNet avvengono cronologicamente prima dell’esecuzione dei layer di normalizzazione stessi. Dopodichè considerando una singola forward pass, il frammento di codice riguardante il calcolo della normalizzazione in moda-lità CPU (perchè all’interno vi è anche la parte riguardante la modamoda-lità in GPU), viene eseguito per ogni normalization layer presente nella rete quando diciamo “è il suo turno” durante la forward pass. Quindi seguendo sempre il nostro esempio, cioè la rete GoogLeNet, il codice viene eseguito esattamente due volte, con i parametri ricavati dal setup di ciascun layer.
Suddividerò ora in che modo vengono eseguite le primitive, o meglio i piccolissimi pezzi di codice, tenute in considerazione:
• setup è il setup iniziale del normalization layer eseguito per tutti i layer, normalization layer compresi, prima della loro esecuzione (come detto prima),
• init rappresenta l’inizializzazione dei valori per effettuare la normaliz-zazione,
• caffe_sqr identifica il calcolo di tutti i quadrati della formula 4.2, • first channel scale indica il calcolo di una scala per il primo canale,
cioè la prima depth slice del volume di input,
• copy previous scale indica la copiatura della scala calcolata prece-dentemente,
• add head identifica l’aggiunta di un offset; qui è presente la primitiva caffe_axpy. Questa primitiva teoricamente serve ad effettuare, opera-zioni del tipo (α ∗ X[i]) + Y [i], dove X[i] ed Y[i] sono gli elementi di due vettori, uno contenente i quadrati calcolati in precedenza e l’altro i valori della scala, mentre α è uno dei parametri impostabili nel layer, • subtract tail identifica la sottrazione di un offset, anche qui
utilizzan-do caffe_axpy ma con parametri diversi al suo interno,
• caffe_powx effettua l’elevamento a potenza con esponente β della formula 4.2. In realtà essendo l’elevamento a potenza al denominatore nella formula in questione, viene effettuato un elevamento a potenza con esponente −β per poter poi effettuare un prodotto invece di una divisione,
• caffe_mul effettua il prodotto fra i valori calcolati da caffe_powx ed i valori di input del layer.
Alcune delle operazioni considerate vengono effettuate solo una volta per l’intera esecuzione di un normalization layer, mentre altre si ripetono più volte. In particolare:
• init, caffe_sqr, first channel scale, caffe_powx, caffe_mul ven-gono eseguite una volta per ciascun layer di normalizzazione
• copy previous scale, add head, subtract tail vengono eseguite per tutti canali del volume di input, per ogni normalization layer. Il numero di canali che ci sono in totale dipende dal volume di input del layer precedente. Possono essere qualche decina o anche qualche centinaia. Stampando questi tempi per ciascuna iterazione, cioè per ogni canale, viene a crearsi un output di più di 2000 righe. Per questo motivo si è preferito, per ciascun layer di normalizzazione, considerare il totale del tempo speso, ovvero per tutti i canali, di ciascuna di queste operazioni.
Misurazione temporale Tempo (s)
setup 0.000043
init 0.002309
sqr 0.000118
first channel scale 0.000021 copy prev. scale 0.000060
add head 0.000078
subtract tail 0.000080
powx 0.012986
mul 0.000120
Total time 1st normalization 0.015815
Tabella 6.4: Dati primo normalization layer di GoogLeNet su PC
Misurazione temporale Tempo (s)
setup 0.000012
init 0.006183
sqr 0.000371
first channel scale 0.000023 copy prev. scale 0.000213
add head 0.000277
subtract tail 0.000227
powx 0.325750
mul 0.000373
Total time 2nd normalization 0.333429
Figura 6.6: Ripartizione tempi primo normalization layer di GoogLeNet
Layer Tempo PC (s) Tempo Android (s)
normalization layer 1 0.016 0.095
normalization layer 2 0.335 0.252
Tabella 6.6: Confronto normalization layer di GoogLeNet fra PC e Android
I risultati ottenuti per ciascuno dei layer di normalizzazione di GoogLeNet su PC sono mostrati nelle tabelle 6.4, 6.5 e nelle figure 6.6, 6.7.
Si evince dunque che più dell’80% del tempo di ciascuna esecuzione di un normalization layer di GoogLeNet su PC è dedicato all’operazione di elevamento a potenza con esponente β per la formula di normalizzazione 4.2. Addirittura sul secondo normalization layer questa operazione ha un tempo di circa 0.32 secondi su un totale di 0.33 secondi del layer. Si suppone che durante questo calcolo entrino in gioco altri fattori come ad esempio il non accurato utilizzo della memoria.
Considerando inoltre che su PC un’intera forward pass di GoogLeNet impiega in media 0.585 secondi (si veda tabella 6.2), si può notare che buo-na parte della percentuale di normalizzazione della figura 6.5(a) è dovuta al secondo normalization layer. Quindi l’operazione di elevamento a potenza rimane decisamente la più onerosa in entrambi i casi, ma nel primo norma-lization layer il suo tempo è molto più contenuto. Il tempo più contenuto probabilmente in parte è dovuto al fatto che, al momento dell’applicazione della prima normalizzazione, il volume in input risulta avere una profondità, cioè un numero di canali, nettamente inferiore rispetto al volume che si ha durante la seconda normalizzazione. Questo fatto lo si intuisce anche dal numero di righe di output ottenute all’interno del ciclo sui canali. Tuttavia confrontando i tempi medi ricavati in precedenza di ciascun normalization layer di GoogLeNet fra Android e PC (nella tabella 6.6 sono riportati i dati d’interesse), si vede che nella prima normalizzazione, nonostante caffe_powx costituisca un buon 80-90% del tempo totale per la normalizzazione stessa, il tempo su PC risulta comunque decisamente più piccolo rispetto a quello su Android, nello specifico 0.02 circa su PC e 0.09 circa su Android, cosa che invece non accade nella seconda normalizzazione. Quindi si ipotizza che con l’aumentare del numero di canali, dato che c’è un balzo di diverse centinaia di unità fra la prima e la seconda normalizzazione, questa operazione non sia diciamo propriamente efficiente su PC.