Forum Ubuntu-it

è possibile sfruttare un processore Dual Core in modo che esegua un programma (scritto per esempio in C) sfruttando il calcolo parallelo? Cioè, supposto che io abbia scritto correttamente le mie righe di codice, è possibile far girare istruzioni compatibili dello stesso programma indipendentemente e parallelamente sui due processori? (per esempio: una simulazione generata "n" volte potrebbe essere generata "n/2" volte da ogni singolo processore dimezzando così il tempo di calcolo?)
Paolo

per fare quello che dici tu devi andare a programmare a basso livello (sul processore)...altrimenti queste cose le gestisce il SO

Devi imparare ad usare i thread.

Capito...cioè, non ho capito ma credo sia complicato...in linea di principio so che è possibile il calcolo parallelo tra calcolatori in rete e allora mi chiedevo se lo stesso principio era applicabile ad un calcolatore con doppio processore

Sì, certo, e a maggior ragione.

in C sono disponibili i thread e la funzione fork()
in java ci sono i thread....per le differenze e per sapere cosa fà meglio al caso tuo dovresti studiare un pò questi linuguaggi e anche un pochino di sistemi operativi....

... approfitto di questo succoso thread ..

Benchè utilizzi i thread come il pane, dite che basta per usare un nCore ?
Non ci sono pure implicazioni riguardanti la memoria le periferiche in uso ecc ecc ?

Proprio per la memoria .. nel caso più semplice .. supponiamo che abbia allocato un pezzo di memoria M, supponiamo anche che non mi stia preoccupando di sincronizzarne gli accessi (Tanto la devo solo leggere)
..
ora, due thread che girano su due core simultaneamente .. riescono entrambi ad accederci .. simultaneamente ?

L'ignoranza mi pervade 

Dipende da cosa intenti per "simultanemante". Se intenti nello stesso preciso nanosecondo, ovviamente no, visto che i due core usano un solo bus.

lurebu ha scritto: Proprio per la memoria .. nel caso più semplice .. supponiamo che abbia allocato un pezzo di memoria M, supponiamo anche che non mi stia preoccupando di sincronizzarne gli accessi (Tanto la devo solo leggere)
..
ora, due thread che girano su due core simultaneamente .. riescono entrambi ad accederci .. simultaneamente ?

Si, in buona approssimazione c'e` vero parallelismo in una situazione del genere.
Poi c'e` tutta una serie di problematiche che derivano dall'accesso concorrente alla memoria che possono creare interdipendenze tra i flussi di esecuzioni e quindi ridurre il parallelismo. Ma son tutte cose che, in prima approssimazione appunto si ignorano

Guiodic ha scritto: Dipende da cosa intenti per "simultanemante". Se intenti nello stesso preciso nanosecondo, ovviamente no, visto che i due core usano un solo bus.

No no .. non intendevo nello stesso Nano anche perchè nello stesso nano, probabilmente non ci accedono nemmeno se girano sullo stesso core.
Intendevo in generale.

Mi chiedevo questa cosa perchè effettivamente sembra esserci in questo caso un vantaggio notevole nell'avere due core invece che per esempio 2 processori o peggio 2 processori su due computer separati (Vabbè ho esagerato). Anche in vista dell'arrivo del 6-core (Si chiamerà esa-core ? bho) che ho letto da qualche parte essere in test.

@Ikitt
Ok, era esattamente quello che volevo sapere.
In sostanza .. il bus è comunque uno .. i core stanno nella stessa scatola .. quindi la memoria (a parte il nano) diciamo che non se la litigano più di tanto ...

Thanks

lurebu ha scritto:

Guiodic ha scritto: Dipende da cosa intenti per "simultanemante". Se intenti nello stesso preciso nanosecondo, ovviamente no, visto che i due core usano un solo bus.

No no .. non intendevo nello stesso Nano anche perchè nello stesso nano, probabilmente non ci accedono nemmeno se girano sullo stesso core.
Intendevo in generale.

Mi chiedevo questa cosa perchè effettivamente sembra esserci in questo caso un vantaggio notevole nell'avere due core invece che per esempio 2 processori o peggio 2 processori su due computer separati (Vabbè ho esagerato). Anche in vista dell'arrivo del 6-core (Si chiamerà esa-core ? bho) che ho letto da qualche parte essere in test.

Dipende, sinche` il memory controller e` su northbridge la differenza e` relativamente poca, sopratutto in presenza di grosse cache.

Pero`, per dire, con i processori con memory controller integrato (amd k8/k10, intel core i7) la situazione cambia a favore del multiprocessore.

Ikitt ha scritto:

lurebu ha scritto:

Guiodic ha scritto: Dipende da cosa intenti per "simultanemante". Se intenti nello stesso preciso nanosecondo, ovviamente no, visto che i due core usano un solo bus.

No no .. non intendevo nello stesso Nano anche perchè nello stesso nano, probabilmente non ci accedono nemmeno se girano sullo stesso core.
Intendevo in generale.

Mi chiedevo questa cosa perchè effettivamente sembra esserci in questo caso un vantaggio notevole nell'avere due core invece che per esempio 2 processori o peggio 2 processori su due computer separati (Vabbè ho esagerato). Anche in vista dell'arrivo del 6-core (Si chiamerà esa-core ? bho) che ho letto da qualche parte essere in test.

Dipende, sinche` il memory controller e` su northbridge la differenza e` relativamente poca, sopratutto in presenza di grosse cache.

Pero`, per dire, con i processori con memory controller integrato (amd k8/k10, intel core i7) la situazione cambia a favore del multiprocessore.

Non sono sicuro di aver capito.
In sostanza essendo integrato, la gestione della memoria 'condivisa' fra più processi in esecuzione su processori separati (Che accedono alla stessa memoria ovviamente) viene gestita meglio ?

lurebu ha scritto:

Ikitt ha scritto:

lurebu ha scritto:

Guiodic ha scritto: Dipende da cosa intenti per "simultanemante". Se intenti nello stesso preciso nanosecondo, ovviamente no, visto che i due core usano un solo bus.

No no .. non intendevo nello stesso Nano anche perchè nello stesso nano, probabilmente non ci accedono nemmeno se girano sullo stesso core.
Intendevo in generale.

Mi chiedevo questa cosa perchè effettivamente sembra esserci in questo caso un vantaggio notevole nell'avere due core invece che per esempio 2 processori o peggio 2 processori su due computer separati (Vabbè ho esagerato). Anche in vista dell'arrivo del 6-core (Si chiamerà esa-core ? bho) che ho letto da qualche parte essere in test.

Dipende, sinche` il memory controller e` su northbridge la differenza e` relativamente poca, sopratutto in presenza di grosse cache.

Pero`, per dire, con i processori con memory controller integrato (amd k8/k10, intel core i7) la situazione cambia a favore del multiprocessore.

Non sono sicuro di aver capito.
In sostanza essendo integrato, la gestione della memoria 'condivisa' fra più processi in esecuzione su processori separati (Che accedono alla stessa memoria ovviamente) viene gestita meglio ?

Mi sono espresso male.
Quel che voglio dire e` che occorre valutare l'architettura complessiva del sistema multiprocessore. I sistemi multicore hanno una serie di limitazioni che possono limitare il parallelismo in maniera maggiore rispetto ai multiprocessori, in virtu` del fatto che hanno piu` componenti condivisi, primo tra tutto il memory controller.
Anche la cache riveste un ruolo importante, e anche qui differenti architetture di processore (amd vs intel) possono avere differenze significative.
Mi aspetto che ci siano delle differenze (cosa che pero` andrebbe verificata, anche se non e` banale farlo) tra due amd athlon64 (singolo core, memory controller integrato), un athlon64 X2 (due core, memory controller integrato), due intel core solo (singolo core), un intel core duo (due core), qualunque sia il confronto.

La programmazione concorrente e` difficile

Ikitt ha scritto: ...
Quel che voglio dire e` che occorre valutare l'architettura complessiva del sistema multiprocessore. I sistemi multicore hanno una serie di limitazioni che possono limitare il parallelismo in maniera maggiore rispetto ai multiprocessori, in virtu` del fatto che hanno piu` componenti condivisi, primo tra tutto il memory controller.

chiarissimo

Ikitt ha scritto: Anche la cache riveste un ruolo importante, e anche qui differenti architetture di processore (amd vs intel) possono avere differenze significative.
Mi aspetto che ci siano delle differenze (cosa che pero` andrebbe verificata, anche se non e` banale farlo) tra due amd athlon64 (singolo core, memory controller integrato), un athlon64 X2 (due core, memory controller integrato), due intel core solo (singolo core), un intel core duo (due core), qualunque sia il confronto.

Ok ok

Ikitt ha scritto:
La programmazione concorrente e` difficile

Ecco, qui sta il punto.
In sostanza, la mia serie di domande riguardava proprio il fatto che essendoci in mezzo una quantità di fattori come questi, potrebbe succedere che un software, per avere dei vantaggi effettivi su un multicore o multiprocessore, non necessiti solo di essere fatto multi-thread ma anche che questi thread siano strutturati in modo molto intelligente.

In altre parole spalmare l'elaborazione su più thread non è detto che automaticamente porti i thread a sfruttare un multicore, o peggio, anche se eseguiti su core diversi non è detto che non si intralcino fra loro nella concorrenza con le risorse condivise.

Quindi .. potremmo dire che siamo ancora lontano dallo sfruttamento dei multicore da parte della maggior parte dei programmatori ? 

io direi di no... se pensi che sw come blender sfruttano decine di processori...

Guiodic ha scritto: io direi di no... se pensi che sw come blender sfruttano decine di processori...

non so .. non direi che la maggior parte dei programmatori siano all'altezza di quelli che hanno sviluppato blender 

non tutti i programmi hanno reali vantaggi con il multithreading

Guiodic ha scritto: non tutti i programmi hanno reali vantaggi con il multithreading

shure !

lurebu ha scritto:

Ikitt ha scritto: La programmazione concorrente e` difficile

Ecco, qui sta il punto.
In sostanza, la mia serie di domande riguardava proprio il fatto che essendoci in mezzo una quantità di fattori come questi, potrebbe succedere che un software, per avere dei vantaggi effettivi su un multicore o multiprocessore, non necessiti solo di essere fatto multi-thread ma anche che questi thread siano strutturati in modo molto intelligente.

In altre parole spalmare l'elaborazione su più thread non è detto che automaticamente porti i thread a sfruttare un multicore, o peggio, anche se eseguiti su core diversi non è detto che non si intralcino fra loro nella concorrenza con le risorse condivise.

Quindi .. potremmo dire che siamo ancora lontano dallo sfruttamento dei multicore da parte della maggior parte dei programmatori ? 

Vero. Non basta usare fork() o pthread_create() per essere a posto. L'architettura del software ha un ruolo di primo piano.
E fare questo e` difficile. E` difficile perche` la programmazione concorrente e` piu` complessa di per se (da 1 flusso di esecuzione a N flussi di esecuzioni), ma anche perche` la piattaforma hardware diventa piu` complessa.
A chiudere il mio discorso sull'hardware di cui sopra, i sistemi multiprocessori-non-multicore sono probabilmente un po piu` facili da usare efficientemente (o almeno mi aspetterei che lo siano) perche` hanno meno componenti condivisi.

Riguardo allo sfruttamento dell'hardware da parte dei programmatori: dipende, ancora. Il campo appunto e` difficile da padroneggiare, e manca generalmente una piattaforma consolidata che semplifichi il lavoro e permetta di astrarre (e forse manchera` sempre se non si vuole ammazzare l'efficienza, e comunque il discorso e` ancora piu` complesso).

Inoltre ci sono fattori culturali. Per gestire la concorrenza efficientemente (e sicuramente, fattore ancor piu` critico) per esempio i classici thread non sono sempre e comunque la scelta migliore; anzi, secondo alcuni non lo sono mai (tendenza alquanto forte nella scena python per esempio, al contrario del mondo java che tende a iper-usare i thread, e anche nel mondo win32 per quel che ne so).
Altri modelli di concorrenza possono essere utili o determinanti: la programmazione asincrona, i thread leggeri/coroutine, o anche i buoni vecchi processi.

Dipende dall'applicazione.
Per esempio, nel caso di server web (statici), singole applicazioni monoprocesso ma che usano la programmazione asincrona (select, (e)poll o framework tipo libevent o twisted)
ottengono spesso prestazioni di assoluto rilievo, quando non le migliori del lotto, e non sono significativamente piu` difficili da programmare del corrispondente multithread (anzi).
Sarebbe lecito aspettarsi quindi prestazioni potenzialmente ancora maggiore da cluster di dette applicazioni con a monte un ripartitore del carico.
Uso il condizionale perche`, sebbene abbia letto di simili configurazioni, non ci ho mai concretamente messo mano.

Ma se ci si pensa bene queste sono appunto applicazioni particolari (poco o nullo stato per richiesta e poca o nulla interdipendenza tra istanze).
Al lato opposto dello spettro (molto stato e sopratutto molto stato condiviso e alta interdipendenza) ci sono applicazioni di calcolo intensivo tipo transcode (http://tcforge.berlios.de , http://www.transcoding.org) -che cito ed uso come esempio perche` conosco molto bene- o molte applicazioni di calcolo scientifico.

In questi casi parallelizzare diventa molto piu` arduo di per se, e oltretutto alcune classi di soluzioni (p.es programmazione asincrona) diventano impraticabili, riducendo ancora lo spazio delle soluzioni e (quindi?) incrementando la difficolta`.

Come se tutto questo (di cui ho a malapena intaccato la superficie nella mia sbrigativa esposizione) non bastasse, c'e` anche da considerare che una rilevante fetta di programmatori si e` formato ed e` cresciuta e vissuta in un mondo monoprocessore (e monopiattaforma) in cui semplicemente tutti questi problemi non si ponevano neppure, e adesso e` forzosamente impreparata.

Piuttosto esaustivo.
Quindi la risposta è 'generalmente' no, non basta spammare thread a casaccio per sfruttare un multicore. Peggio per un multiprocessore. Assolutamente inutile per un cluster.

Evidentemente con tutte le eccezioni del caso  (b2b)

Che significa, riagganciandosi all'inizio del thread, che se vuoi sfruttare il parallelismo non è sufficiente che ti impari ad usare i thread (Anche se è condizione comunque necessaria) ma è necessario che strutturi il codice, (ed acquisisci le conoscenze) per una vera elaborazione parallela.

Con buona pace per tutti.

NB
In realtà, in ambiente win32, sopratutto sullo sviluppo di applicazioni in ambienti rad, i compilatori (o se vogliamo interpreti) hanno 'asicronizzato' almeno l'interfaccia utente. In sostanza i programmatori single thread a loro insaputa, stanno già spammando thread a destra e a manca.