Newsgroup: it.comp.macintosh
Titolo: Dubbi sulle applicazioni multi-threaded

Salve a tutti,
io di programmazione non ne capisco nulla ma mi chiedevo una cosa.
Vi pare possibile che un applicazione scritta/ottimizzata per sfruttare
configurazioni multi CPU/Core possa essere scritta per sfruttare al
massimo un determinato numero di CPU/Core?
Prendiamo ad esempio QuickTime Player Pro: in qualsiasi codifica lancio
sul Mac Pro non si superano mai i 200% cicli di CPU sui 400%
disponibili. Anche dando la massima priorità al processo ($ sudo renice
-20 #PID) il massimo che ottengo è un 200% fisso.
È come se QT fosse in grado sfruttare al massimo 2 CPU/Core.
È possibile? Io pensavo che un'applicazione multithreaded fosse in grado
di "segmentarsi" il lavoro automaticamente in modo da far lavorare e
quindi sfruttare al meglio tutte le unità di calcolo disponibili ma a
quanto pare non è così :(
QT Pro è solo un esempio, ho notato questo comportamento in tante altre
applicazioni (soprattuto quando si parla di codifica video).
Altra cosa dal comando top via terminale la quinta colonna riporta il
numero di thread, giusto? Come mai, riprendendo come esempio QT Pro, un
processo con in media una decina di thread (conversione da MPEG2 a
formato iPod) non riesce ad occupare comunque tutti i cicli di CPU
disponibili? È un problema di ottimizzazione o è sempre un problema del
limite a cui facevo riferimento prima o più semplicemente il numero di
tread riportati in quella colonna non ha nulla a che vedere con questa
faccenda?
Ok ok, fine seghe mentali, torno alle mie presentazioni... solo che non
sarebbe male sfruttarlo sempre e comunque questo quedricefalo :)
-- 
"Imagination is more important than knowledge"
Albert Einstein 
1879-1955 

 faccenda?
Questo è semplicemente che MacOS X tende a non saturare tutto, quando
può.Effettivamente da te potrebbe saturare più della metà. non saprei.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 può.Effettivamente da te potrebbe saturare più della metà. non saprei.
Ho idea che solo con i futuri OS (e app) si potrà sfruttare al meglio un
sistema multi-CPU/Core. Ad oggi sono veramente poche le applicazioni
(tra quelle che uso io ovviamente) che sotto carico arrivano ad occupare
i 4 core al massimo (sopra i 350%).


 i 4 core al massimo (sopra i 350%).
Non dipende dal futuro o dal presente. Dipende dal fatto che
l'applicazione puo` o meno essere parallelizzabile e nel caso lo possa
essere quanto. Occupare piu` core non e` necessariamente un vantaggio e
comunque averne a disposizione di liberi permette di eseguire piu`
calcoli diversi nello stesso tempo.
-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: 
http://vvolonghi.blogspot.com
New Pet: 
http://www.stiq.it

 -20 #PID) il massimo che ottengo è un 200% fisso.
Cosa usi per verificare il consumo di CPU?
giordano

 wrote:

Activity monitor per un riscontro grafico immediato (mela+5 o mla+4) o
il classico "top" via terminale ("top -s 5 -u" per essere precisi).


 calcoli diversi nello stesso tempo.
Certo, ma stiamo parlando di applicazioni che *si* potrebbero trarre
grossi benefici se solo fossero in grado di far lavorare 4 teste al 100%
invece che al 25%.


 il classico "top" via terminale ("top -s 5 -u" per essere precisi).
Allora avrei una domanda da ignorantone.  :)
Parlando di Activity monitor e di sistemi ATA, č fondata la mia
sensazione che quando un processo lavora pesantemente con la sua
personale cache su disco (quindi non con la memoria virtuale di sistema)
il lavoro che la CPU deve sostenere per realizzare la lettura e la
scrittura non entra nel calcolo del carico che viene attribuito al
processo?
Grazie mille.
giordano

 processo?
Non ho capito la domanda :)


 Non ho capito la domanda :)
Mi sa che ritiro tutto.  x:)
Osservando Activity Monitor avevo pensato che le operazioni di disco di
Photoshop fossero meno 'cariche' rispetto ad altre perché l'attività
sostenuta dalle CPU per la gestione delle operazioni di
lettura/scrittura non venivano attribuite direttamente all'applicativo,
ma guardando il grafico che si ottiene con Mela-4 credo di aver capito
che è Photoshop a caricare meno. Probabilmente alcune parti del
programma pensano di usare solo una CPU ed è poi OSX a distribuire i
calcoli tra le unità presenti.
giordano

 calcoli tra le unità presenti.
Potresti anche essere a corto di RAM: quando la RAM scarseggia i
processori non vengon o sfruttati al massimo perché si perde un'infinità
di tempo con lo swap su disco fisso.


 Potresti anche essere a corto di RAM
La RAM abbonda, e nell'ultimo test ho tenuto il documento abbastanza
piccolo da fare swappare Photoshop il minimo indispensabile. Ciò
premesso, per via di come è fatto il programma di swap probabilmente ce
n'è, ma per me il punto era capire se il lavoro che i sistemi ATA
richiedono alle CPU viene gestito al massimo, e la mia impressione è che
non sia così.
Durante questo lavoro, mentre un paio di CPU lavorano sodo, le altre
sembrano caricare processi leggeri tra i quali c'è forse lo stesso
Activity Monitor. Fatto sta che le meccaniche frullano ad intermittenza
per periodi di un secondo circa intervallati da pause più lunghe (il
tempo totale di scrittura è molto superiore a quello che ci si
aspetterebbe anche calcolando una integrale lettura del documento da un
file di swap) mentre il carico complessivo delle CPU è più o meno
costante e pari a circa il 120%: il collo di bottiglia sembrerebbe
dunque essere a livello di processori.
IOW, certi compiti mi sembra vengano indirizzati su una sola CPU
risultando di conseguenza relativamente lenti rispetto ad altri anche
quando il sistema operativo li distribuisce. 
Resta solo da verificare se sto scrivendo cretinate a quintali.  x:)
Già che ci siamo, a proposito di RAM, mi piacerebbe avere una conferma:
mi sembra di capire che attualmente un processo dotato di GUI non può
superare i 2 GB di RAM e che solo con il rilascio di OSX.5 ci sarà
qualche speranza di vedere cambiare la situazione. È corretto?
giordano

 qualche speranza di vedere cambiare la situazione. È corretto?
In linea di massima si. Anche se probabilmente via GUI si possono
comunqe mandare processi di basso livello bypassando questo limite...
almeno credo.


 quanto pare non è così :(
Mi e' appena venuto in mente.
Potrebbe essere (ma qui sono in pura ipotesi) che OSX non puo' mettere
per qualche strano motivo (ad esempio problemi di indirizzamento della
memoria) threads diverse, ma che fanno capo allo stesso processo su
processori diversi. Cioe' puo' mettere 2 thread dello stesso processo a
funzionare nei 2 core dello stesso processore, ma non in 2 core di due
processori diversi.
Come si comportava OSX sui dual G5 mono core? per capire se e' un
problema di OSX o di architettura degli intel...
Ciao Jack

 problema di OSX o di architettura degli intel...
Non saprei... la generazione G5 l'ho saltata :|


 problema di OSX o di architettura degli intel...
Questo è un problema di chache. Un processo attivo può essere spezzato e
ricomposto per essere suddiviso su più core e più processori, ma il modo
di spezzare è dovuto alla natura delle operazioni, che se sono
consecutive, ovvero i risultati della pipeline tornano in chache per
essere riutilizzati nelle operazioni successive, non si possono
suddividere su più processori. Una codifica video o audio non ha di
questi problemi e può essere spezzata abilmente.
Che OSX, e tutti i *nix, non dividano su più processori uno stesso
processo posso capirlo, in quanto per farlo bisognerebbe adottare
tecniche di calcolo distribuito che va bene per mega calcoli di genoma
umano, ma per i task del sistema operativo di un pirla che guarda le
donnine ignude su internet è troppo. Distribuire su due o più core un
processo invece è più normale, si tiene un solo processo attivo, su cui
il sistema calcola tempi, accessi, priorità sul processore, e si
dividono solo i calcoli. Su più processori tempi accessi e priorità
potrebbero essere diversi e avere "pezzi" di processo che vanno a una
velocità e pezzi che vanno a un'altra, creando non poco imbarazzo su chi
programma il sistema operativo che diventa un esperto di puzzle....
Poi, questo pensiero fa parte del mio bagaglio di appassionato, espetto
che qualcuno mi corregga se dico castronate!!!
-- 
Guru       Non coltivate i beni terreni,
               non rimarrà niente.
         Coltivate l'amore delle persone,
            vale più di qualsiasi oro. 

 almeno credo.
Anche io ho letto che è così, ma mi sembra che Photoshop non sfrutti
questa possibilità.
giordano

 invece che al 25%.
Il problema nasce nel far ragionare quattro teste con due memorie
differenti. I processori Intel hanno la cache L2 che per i Core è
comune, ma ce ne sono due distinte per i due processori, quindi più che
quattro teste al 100% sono due teste che vanno a 100, e le altre due che
fanno altro....


 fanno altro....
No, il problema nasce dal fatto che l'algoritmo di conversione del
filmato usa un algoritmo che non e` stato parallelizzato su piu` di 2
thread. La cache viene partizionata e ognuno usa la sua.


 thread. La cache viene partizionata e ognuno usa la sua.
Ma la programmazione multitreading non può avere limiti di tread, è
assurdo, si dovrebbe riprogrammare appena escono i quadCore. È invece
più sensato pensare che un task possa essere eseguito su un solo
processore, ma sfruttando tutti i suoi core che hanno la stessa cache
L2, il processo genera poi molti tread che vengono instradati verso il
core libero al momento fino a saturarli tutti, ma non andando a
sfruttare i core dell'altro processore che ovviamente non hanno lo
stesso task, ma ne eseguono altri.....


 stesso task, ma ne eseguono altri.....
Non mi sembra che tu abbia mai programmato vero? :).
La programmazione multithreading HA limiti di thread eccome,
specialmente nell'implementazione degli algoritmi, puoi fare in modo che
un thread operi su un set di dati e l'altro thread sull'altro. Ma
salendo il numero dei thread aumentano anche il numero delle operazioni
necessarie per la sincronizzazione degli stessi finche` diventa piu`
dispendioso sincronizzarli che ottenere il risultato del loro lavoro.
Il set di dati inoltre potrebbe non essere partizionabile in modo
adeguato o la sua partizionatura (e riunione dei risutati) potrebbe
richiedere piu` calcoli del dovuto o essere comunque a sua volta un
problema complesso (se si vuole fare in automatico).
Non e` mica cosi` semplice come la fai tu.


 Non e` mica cosi` semplice come la fai tu.
Eh, lo so, ma nel tenermi informato tendo sempre a cercare di convertire
la mole di informazioni che acquisisco in modo da farli diventare
semplici e ben ricordabili, in maniera da poterlo spiegare anche a un
bambino se fosse necessario, e forse mi capita di semplificare troppo
alle volte....
Sarà che che anche il mio cervello ha problemi di sincronizzazione dei
thread?? :-D


 thread?? :-D
E` facile averne, chiunque ne ha in realta` :).



Scusa ma il codice che implementa le operazioni su un semaforo secondo
te non implementano un algoritmo di sincronizzazione?
A me sembra di si.

 A me sembra di si.
Si e` vero, ma la definizione di algoritmo e` davvero ampia per certi
versi. Dipende dal livello di astrazione a cui ti collochi, al livello
di astrazione giusto anche assegnare un valore alla variabile diventa un
algoritmo. Noi qua si volava alti.



