problema con parametro int di una funzione
GiuseppeDini
un altro pc.
In pratica mi è successo con le librerie dell’open source per la
computer vision “OpenCV”.
I file sorgenti prevedono la creazione attraverso Cmake delle soluzioni
per compilare i file scegliendo le varie opzioni.
Io su un pc dual core con Vista su cui ho installato visual C++ express
ho scelto l’opzione funzionante senza OMP e su un XP con un solo
processore con Visual Studio 2008 Professional l’opzione con OMP.
Ho compilato i file e tutto va bene sui rispettivi pc.
In pratica è un programma di facedetection.
Ho provato a portare i file compilati su XP su Vista e il comportamento
cambia un po’.
Dopo alcune indagini mi sembra di capire che tutto derivi da un
parametro intero di una funzione: se, quando compilo su XP, aumento il
valore trasmesso a quella funzione, il risultato su Vista è quello
desiderato.
Sembrerebbe quasi che sui file spostati su un altro pc vengano alterati
i valori di quel parametro.
E’ possibile una cosa del genere?
--
Giuseppe
![Raffaele Rialdi [MVP]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Raffaele Rialdi [MVP]
> altro pc.
Certamente si e le motivazioni sono tantissime e dipendono da quello
che hai scritto.
> In pratica mi è successo con le librerie dell’open source per la computer
> vision “OpenCV”.
> I file sorgenti prevedono la creazione attraverso Cmake delle soluzioni per
> compilare i file scegliendo le varie opzioni.
Se le librerie sono C dovrebbero essere linkate senza problemi.
Se sono classi C++ esportate *devono* essere compilate con lo stesso
compilatore (marca e versione). Non esiste compatibilità binaria in C++
(parlo in genere non solo di VC++).
> Io su un pc dual core con Vista su cui ho installato visual C++ express ho
> scelto l’opzione funzionante senza OMP e su un XP con un solo processore con
> Visual Studio 2008 Professional l’opzione con OMP.
> Ho compilato i file e tutto va bene sui rispettivi pc.
> In pratica è un programma di facedetection.
> Ho provato a portare i file compilati su XP su Vista e il comportamento
> cambia un po’.
> Dopo alcune indagini mi sembra di capire che tutto derivi da un parametro
> intero di una funzione: se, quando compilo su XP, aumento il valore trasmesso
> a quella funzione, il risultato su Vista è quello desiderato.
> Sembrerebbe quasi che sui file spostati su un altro pc vengano alterati i
> valori di quel parametro.
> E’ possibile una cosa del genere?
Se capisco bene hai usato il programma senza OMP su Vista e hai un
comportamento diverso da quello con OMP su Vista.
In questo caso è normale avere comportamenti differenti.
- innanzitutto lo scheduler di Windows nelle due versioni è molto
diverso. Quindi la schedulazione dei thread avviene in modo differente
- poi un programma abilitato per OMP gira su più thread e perciò ha un
binario decisamente differente da uno che non usa OMP
- Inoltre anche senza usufruire di più CPU la schedulazione di più
thread su un core o su più core è un altro punto di diversita.
Se devi sfruttare la parallelizzazione ti consiglio di passare a VS2010
(che uscirà in RTM a Marzo) perché include le PPL (Parallel Pattern
Library) e le AAL (Asynchronous Agents Library) oltre a un altro set di
librerie managed.
La semplificazione e il runtime che ti permette di decidere a runtime
il livello di parallelizzazione sono impagabili
Per riferimento guarda qui:
http://blogs.msdn.com/nativeconcurrency/
--
Raffaele Rialdi http://www.iamraf.net
Weblog: http://blogs.ugidotnet.org/raffaele
Microsoft .NET MVP http://mvp.support.microsoft.com -
UGIdotNET - http://www.ugidotnet.org
GiuseppeDini
> Se le librerie sono C dovrebbero essere linkate senza problemi.
> Se sono classi C++ esportate *devono* essere compilate con lo stesso
Adesso che ci penso, avevo dato per scontato che anche le funzioni c++
fossero state compilate con l'opzione extern "C".
Ma vedendo il codice non sembra che sia cosￜ.
Inoltre con depency walker appaiono "decorate".
Sarￜ possibile che questo vada ad inficiare il valore di un parametro
intero di una funzione?
> Se capisco bene hai usato il programma senza OMP su Vista e hai un
> comportamento diverso da quello con OMP su Vista.
> In questo caso ￜ normale avere comportamenti differenti.
> - innanzitutto lo scheduler di Windows nelle due versioni ￜ molto diverso.
> Quindi la schedulazione dei thread avviene in modo differente
> - poi un programma abilitato per OMP gira su piￜ thread e perciￜ ha un
> binario decisamente differente da uno che non usa OMP
> - Inoltre anche senza usufruire di piￜ CPU la schedulazione di piￜ thread su
> un core o su piￜ core ￜ un altro punto di diversita.
Per essere piￜ precisi, la funzione di OpenCv che effettua la face
detection, fa la scansione di un'immagine passando una finestra in
tutte le posizioni e memorizza in un vettore i dati nel caso in cui
ritenga che ci sia una faccia.
Il parametro intero che dￜ problemi si chiama "minNeighbors" che
imposto su 2: se due o piￜ finestre molto vicine danno esito positivo,
altrimenti scarta il dato.
La cosa strana ￜ che se cambio il valore da 2 ad un numero maggiore di
35, per esempio, funziona nello stesso modo.
Devo solo incrementare il valore e tutto funziona come prima.
???
> Se devi sfruttare la parallelizzazione ti consiglio di passare a VS2010 (che
> uscirￜ in RTM a Marzo) perchￜ include le PPL (Parallel Pattern Library) e le
> AAL (Asynchronous Agents Library) oltre a un altro set di librerie managed.
> La semplificazione e il runtime che ti permette di decidere a runtime il
> livello di parallelizzazione sono impagabili
> Per riferimento guarda qui:
> http://blogs.msdn.com/nativeconcurrency/
Purtroppo per il programma OpenCv non dipende da me, ma dagli autori.
:)
--
Giuseppe
Raffaele Rialdi [MVP]
> fossero state compilate con l'opzione extern "C".
Il che presuppone a funzioni globali, cioￜ che con C++ hanno poco a che
fare :)
> Inoltre con depency walker appaiono "decorate".
> Sarￜ possibile che questo vada ad inficiare il valore di un parametro intero
> di una funzione?
No, al massimo ti arriva un unresolved external perchￜ non corrisponde
l'export
> Per essere piￜ precisi, la funzione di OpenCv che effettua la face detection,
> fa la scansione di un'immagine passando una finestra in tutte le posizioni e
> memorizza in un vettore i dati nel caso in cui ritenga che ci sia una faccia.
> Il parametro intero che dￜ problemi si chiama "minNeighbors" che imposto su
> 2: se due o piￜ finestre molto vicine danno esito positivo, altrimenti scarta
> il dato.
> La cosa strana ￜ che se cambio il valore da 2 ad un numero maggiore di 35,
> per esempio, funziona nello stesso modo.
> Devo solo incrementare il valore e tutto funziona come prima.
> ???
Evidentemente l'algoritmo funziona in modo diverso e il flusso eseguito
dalla CPU ￜ simile a quello dell'altro caso.
Sei al caso limite di un bug. In pratica se l'algoritmo riesce a
processare prima una porzione di immagine si comporta in un modo
altrimenti si comporta in un altro. *Sembra* poco stabile ...
> Purtroppo per il programma OpenCv non dipende da me, ma dagli autori. :)
pace e bene :)
GiuseppeDini
> CPU ￜ simile a quello dell'altro caso.
Da notare anche che sul computer su cui sono state compilate le
librerie con OMP va tutto bene.
> Sei al caso limite di un bug. In pratica se l'algoritmo riesce a processare
> prima una porzione di immagine si comporta in un modo altrimenti si comporta
> in un altro. *Sembra* poco stabile ...
Senza sapere di preciso cosa succede, sembrerebbe che il multithread
porti a rilevare piￜ volte lo stesso oggetto.
Nel codice l'unico differenza tra le due compilazioni sono queste tre
righe:
#ifdef _OPENMP
#pragma omp parallel for num_threads(max_threads) schedule(dynamic)
#endif
Nel .Net le volte che ho usato il multithreading non ￜ stato cosￜ
facile perchￜ occorrere prevedere il comportamento di ogni singolo
thread.
Sembra che con OMP basti quel codice per istruire il programma a fare
tutto da solo.
--
Giuseppe
Raffaele Rialdi [MVP]
> rilevare piￜ volte lo stesso oggetto.
Questo sarebbe grave oppure magari un errore di configurazione
>
> Nel codice l'unico differenza tra le due compilazioni sono queste tre righe:
>
> #ifdef _OPENMP
> #pragma omp parallel for num_threads(max_threads) schedule(dynamic)
> #endif
>
> Nel .Net le volte che ho usato il multithreading non ￜ stato cosￜ facile
> perchￜ occorrere prevedere il comportamento di ogni singolo thread.
> Sembra che con OMP basti quel codice per istruire il programma a fare tutto
> da solo.
Lui parallelizza ma poi ci sono enne cose di cui tenere conto.
Devi informare OMP delle variabili condivise, di quelle da mantenere
nel TLS, etc. etc.
Se non lo fai puￜ succedere di tutto e ovviamente dipende da come hai
scritto l'algoritmo. Bisogna capire se quel listato ￜ stato testato
adeguatamente oppure ￜ stato preparato a funzionare con OMP alla veloce
e basta.
Tieni presente che unit testing su algoritmi paralleli non puￜ
funzionare perchￜ a seconda dell'hardware e dalla configurazione
dell'OS le cose possono funzionare in modo radicalmente differente.
Attualmente ci sono dei tool in giro per fare testing (per esempio
Chess) ma sono ancora in fase evolutiva.
GiuseppeDini
>> Nel codice l'unico differenza tra le due compilazioni sono queste tre
>> righe:
>>
>> #ifdef _OPENMP
>> #pragma omp parallel for num_threads(max_threads) schedule(dynamic)
>> #endif
>>
>> Nel .Net le volte che ho usato il multithreading non ￜ stato cosￜ facile
>> perchￜ occorrere prevedere il comportamento di ogni singolo thread.
>> Sembra che con OMP basti quel codice per istruire il programma a fare tutto
>> da solo.
>
> Lui parallelizza ma poi ci sono enne cose di cui tenere conto.
> Devi informare OMP delle variabili condivise, di quelle da mantenere nel TLS,
> etc. etc.
Nel codice non mi sembra che ci sia niente di particolare oltre quelle
tre linee di codice.
Perￜ il programma ￜ talmente grande e complesso che ￜ probabile che
qualcosa mi sia sfuggito.
> Se non lo fai puￜ succedere di tutto e ovviamente dipende da come hai scritto
> l'algoritmo. Bisogna capire se quel listato ￜ stato testato adeguatamente
> oppure ￜ stato preparato a funzionare con OMP alla veloce e basta.
Gli autori hanno ammesso di aver riscontrato anche loro qualche
problema e che devono risolverlo, anche se non sono stati piￜ precisi.
> Tieni presente che unit testing su algoritmi paralleli non puￜ funzionare
> perchￜ a seconda dell'hardware e dalla configurazione dell'OS le cose possono
> funzionare in modo radicalmente differente.
> Attualmente ci sono dei tool in giro per fare testing (per esempio Chess) ma
> sono ancora in fase evolutiva.
Grazie ancora.
--
Giuseppe
Raffaele Rialdi [MVP]
> linee di codice.
> Perￜ il programma ￜ talmente grande e complesso che ￜ probabile che qualcosa
> mi sia sfuggito.
Il problema ￜ che dipende dall'algoritmo e non si puￜ dire a priori.
Bisogna partire dall'analisi degli stati e verificare che non ci siano
possibili race conditions durante la parallelizzazione
> Gli autori hanno ammesso di aver riscontrato anche loro qualche problema e
> che devono risolverlo, anche se non sono stati piￜ precisi.
Mi sembra plausibile quindi che il problemino ci sia.
Oltre a possibili race conditions, ci puￜ essere un problema intrinseco
all'algoritmo.
Tempo fa in una sessione ho mostrato come l'algoritmo di dithering di
Floyd-Steinberg sia apparentemente parallelizzabile in modo semplice.
Se lo fai vedi un netto guadagno ma poi vedi la "cucitura" tra le due
immagini processate dai due core.
Questo ￜ ovvio se pensi a come ￜ fatto l'algoritmo che diffonde
l'errore sui pixel adiacenti. La seconda metￜ dell'immagine parte con i
resti degli errori a zero invece di quelli della fine della prima metￜ
dell'immagine, e di conseguenza vedi la cucitura.
Esistono tecniche alternative ma l'algoritmo va totalmente riscritto e
ripensato, cosa assolutamente non ovvia nￜ banale.
GiuseppeDini
>> Nel codice non mi sembra che ci sia niente di particolare oltre quelle tre
>> linee di codice.
>> Perￜ il programma ￜ talmente grande e complesso che ￜ probabile che
>> qualcosa mi sia sfuggito.
>
> Il problema ￜ che dipende dall'algoritmo e non si puￜ dire a priori.
> Bisogna partire dall'analisi degli stati e verificare che non ci siano
> possibili race conditions durante la parallelizzazione
>
>
>> Gli autori hanno ammesso di aver riscontrato anche loro qualche problema e
>> che devono risolverlo, anche se non sono stati piￜ precisi.
>
> Mi sembra plausibile quindi che il problemino ci sia.
>
> Oltre a possibili race conditions, ci puￜ essere un problema intrinseco
> all'algoritmo.
> Tempo fa in una sessione ho mostrato come l'algoritmo di dithering di
> Floyd-Steinberg sia apparentemente parallelizzabile in modo semplice.
> Se lo fai vedi un netto guadagno ma poi vedi la "cucitura" tra le due
> immagini processate dai due core.
> Questo ￜ ovvio se pensi a come ￜ fatto l'algoritmo che diffonde l'errore sui
> pixel adiacenti. La seconda metￜ dell'immagine parte con i resti degli errori
> a zero invece di quelli della fine della prima metￜ dell'immagine, e di
> conseguenza vedi la cucitura.
>
> Esistono tecniche alternative ma l'algoritmo va totalmente riscritto e
> ripensato, cosa assolutamente non ovvia nￜ banale.
Ok, grazie anche di questa "chicca"!
Ciao :)
--
Giuseppe
Raffaele Rialdi [MVP]
> Ciao :)
Prego, ciao