Approfondimento MOTORE riconoscimento etichette

Approfondimento MOTORE riconoscimento etichette
Un anno fa, quando la prima versione del motore di riconoscimento vedeva la luce, e veniva presentata la
prima offerta alla cooperativa Primo Principio, il sistema lavorava in modo strettamente sequenziale,
intendendo con ciò che l'immagine inviata dal client veniva confrontata con tutte quelle presenti sul
database generando un unico carico di lavoro da far eseguire al processore, ottenendo come risultato che il
tempo di elaborazione totale era calcolabile come prodotto tra il tempo medio del singolo confronto ed il
numero di elementi presenti sul database.
Questo approccio però, sfruttava in modo insoddisfacente le potenzialità hardware del server su cui era
installato, in pratica non venivano sfruttati i notevoli vantaggi offerti dalle moderne architetture dei
processori multicore. L'applicazione dell'approccio sequenziale, ha come effetto che, di tutti i core disponibili
solo uno venga incaricato di eseguire l'intero carico di lavoro.
Volendo quantificare numericamente l'affermazione, e prendendo in esame un processore quad-core
(esempio intel i7 3.2Ghz), considerato che il numero di core viene virtualmente raddoppiato grazie al
meccanismo dell'hyperthreading si hanno a disposizione 8 core identici tra loro, di cui però, solo uno viene
utilizzato, si può affermare che la percentuale di utilizzo della potenza di calcolo non potrà mai superare il
12.5%.
Conseguenza di questo fatto è che a parità di intervallo temporale si possono analizzare circa
elementi rispetto al caso di massima ottimizzazione.
1/8 degli
Dati sperimentali raccolti in questa modalità di funzionamento (sequenziale) ci permettono di stimare i tempi
medi del singolo confronto intorno agli 86 ms. Considerando che l'uso di questo sistema è rivolto ad
applicazioni mobili, nelle quali i tempi di risposta, per risultare accettabili dall'utenza, devono restare entro
al massimo una decina di secondi, otteniamo i dati per stabilire il numero massimo di elementi per categoria
che si fissano quindi in poco più di un centinaio (circa 116 in 10 secondi), per questo nell'offerta del
24/06/2011 si era parlato di un limite di 60 elementi.
Voler aumentare il numero di elementi in database significherebbe quindi, aumentare i tempi di risposta del
sistema in modo (quasi) lineare.
Queste considerazioni hanno portato alla necessità di una prima revisione della tecnologia, che permettesse
di diminuire i tempi di confronto per poter aumentare il numero di elementi confrontabili.
Oggi esiste una versione del software che sfrutta il meccanismo del multithreading il quale permette di
distribuire il carico di lavoro su tutti i core a disposizione, in pratica, invece di considerare i 100 confronti di
cui sopra come un pacchetto computazionale unico, li si fraziona in tanti pacchetti di lavoro atomici quanti
sono gli elementi da comparare, che vengono indirizzati attraverso lo scheduler del sistema operativo a tutti
e 8 i core a disposizione.
In ogni caso con questo approccio si sono ottenuti tempi medi di confronto pari a circa 21 ms, con un uso
della potenza di calcolo a disposizione di circa il 50%, ottenendo entro l'intervallo temporale stimato dei 10
secondi la possibilità di effettuare circa 480 confronti.
Considerando che il numero di confronti nella finestra temporale potrebbe non essere sufficiente si è
proceduto a scopo conoscitivo ad un test che portasse il numero di elementi a 3000, ottenendo conferma del
fatto che la crescita del tempo totale risulta comunque quasi lineare ma che la gestione della RAM diventa
totalmente inefficiente, infatti dato che per permettere allo scheduler di sistema di pianificare le esecuzioni
tutti i thread devono essere pronti a partire al tempo zero, si ottiene che l'intero database composto da
3000 immagini deve essere caricato in RAM, portando ad una sua inevitabile saturazione entro tempi
brevissimi.
Il passo successivo è dunque stato quello di una terza revisione del codice che ha portato allo sviluppo di
una architettura di calcolo altamente parallela (stile GRID), che non sia quindi più affetta da problemi
SANE Biometrics Srl
S.P. 55 Porto Conte – Capo Caccia Km 8,400
Loc. Tramariglio 07041 Alghero (SS) ITALY
P.I. 02405980901
www.sanebiometrics.com
[email protected]
tel. +39 079 998 496
Approfondimento MOTORE riconoscimento etichette
inerenti la schedulazione dei thread e di gestione della RAM a livello di sistema operativo ma che gestisca le
risorse hardware in modo proprietario. Dedicando 7 degli 8 core a disposizione (lasciandone uno libero per le
operazioni di sistema) si è arrivati a percentuali di utilizzo del processore prossime al 85% (circa il 100% dei
7 dedicati) con tempi medi di confronto pari a circa 11 ms, ottenendo quindi la possibilità di effettuare entro
la finestra temporale dei 10 secondi ben 910 confronti.
Ulteriore vantaggio di questo ultimo approccio sta nel fatto che, quando si dovesse presentare la necessità
di scalare ulteriormente il numero di confronti, sarebbe possibile senza sforzi eccessivi, affiancare un
secondo server che metta a disposizione ulteriori core che contribuiranno alla formazione della potenza di
calcolo totale.
SANE Biometrics Srl
S.P. 55 Porto Conte – Capo Caccia Km 8,400
Loc. Tramariglio 07041 Alghero (SS) ITALY
P.I. 02405980901
www.sanebiometrics.com
[email protected]
tel. +39 079 998 496