multi-core = multi-thread != multi-task giusto?

[Walkingcontradiction]

A chi sostiene che gli esacore (o i prossimi 8 core) purtroppo non vengono sfruttati come si deve dagli applicativi attuali, viene risposto spesso con frasi del tipo: "ma con tutti i processi aperti in windows più core si hanno meglio è", "se hai tanti processi aperti riesci a sfruttare meglio tutti i core", ecc.
Io nel mio piccolo penso che queste affermazioni siano assolutamente erronee.
Sbaglio?
Mi spiego (scusate la terminologia non proprio forbita):
Un processo in esecuzione ha un proprio spazio di memoria (una propria tabella delle pagine, ecc), oltre ad una serie di altre informazioni/risorse associate/allocate. Per brevità si dice che un processo è associato ad un proprio contesto. Quando lo scheduler (anzi più precisamente il dispatcher) mette in esecuzione un altro processo (sospendendo temporaneamente il prcedente) effettua un cambio di contesto. In particolare associa una nuova tabella delle pagine con conseguente cambio dello spazio di memoria (sto parlando di memoria virtuale non è il caso di addentrarmi troppo). Ora, secondo me, ad ogni istante può esserci un solo processo in esecuzione in quanto il sistema operativo, ma anche l'hw, non sono predisposti a gestire più contesti contemporaneamente. Come si suol dire, ad ogni istante un solo processo ha il possesso del processore. I multi-core diventano utili nel momento in cui tali processi possiedono più di un flusso di esecuzione (threads). In questo caso i flussi eseguiti in maniera concorente vengono eseguiti in maniera realmente parallela e non a divisione di tempo come avviene nel caso di un normale single-core. Questo è senza dubbio un vantaggio in termini di tempo di esecuzione, ma sempre nell'ambito dell'esecuzione di un singolo processo. Da qui discende la mia obiezione a chi pensa che i vari processi attivi sulla macchina vengano assegnati ai vari core disponibili. Non mi pare proprio possibile.
Che ne pensate?

[Jo3]

Ora, secondo me, ad ogni istante può esserci un solo processo in esecuzione in quanto il sistema operativo, ma anche l'hw, non sono predisposti a gestire più contesti contemporaneamente.

Non fare l'errore di pensare che tutti i processi siano sempre in stato di pronto per essere eseguiti dalla CPU.

E' vero : alla fin fine, la cpu (single core) esegue un processo fisico per volta : PERO' :

I processi in esecuzione a volte rimangono in attesa (coda processi in attesa) proprio perche' la CPU e' molto piu veloce rispetto ai tempi di attesa delle periferiche (prova ad immaginare il tempo-uomo paragonato al tempo-macchina : una persona impega SECONDI per premere un solo tasto e nel frattempo la cpu e' andata avanti di miliardi di istruzioni).
Quel tempo che la cpu spreca per attendere che il processo si svegli e' un tempo morto per la cpu : per questo motivo alla fine la resa su un sistema multi processo e' molto piu elevata

Molto meglio mandare il processo "a nanna" (nella coda dei processi in attesa

Pertanto il fatto che in un singolo processore ci sia un solo processo "REALE" non vuol dire che sia un collo di bottiglia : anzi : molti processi rimangono nella coda dei processi in attesa proprio perche' stanno attendendo l'input da periferiche esterne.

Pertanto avere piu cpu significa avere piu' possibilità nel momento in cui alcuni processi che erano in attesa vengono spostati nella coda dei processi pronti dallo scheduler.

INOLTRE

Un processo non e' detto che quando va in esecuzione debba per forza interessare le periferiche "piu lente" : ovvero quelle che hanno un solo controller e non puo essere virtualizzato. (es : il disco fisso e' unico, pertanto il controller viene utilizzato da uno e un solo processo).

A volte il processo esegue solo delle operazioni in memoria, pertanto non esiste collo di bottiglia.


P.S :
Non a caso, i multi core aumentano la frequenza quando capita una situazione simile, consentendo nei "Burst" di processi pronti di smaltire prima i processi.

[calabar]

Mi chiedo su quale base tu affermi questo:

Originariamente inviato da Walkingcontradiction

Ora, secondo me, ad ogni istante può esserci un solo processo in esecuzione in quanto il sistema operativo, ma anche l'hw, non sono predisposti a gestire più contesti contemporaneamente.

Sinceramente credo che i sistemi operativi attuali siano perfettamente in gradi di gestire, su core differenti, più processi in contemporanea.
Certamente alcune risorse hardware rimarranno condivise, ma se il loro accesso non è limitante, questo non dovrebbe creare problemi.

Del resto il passaggio tra "thread" e "processi" non è così definito.
Per semplicità diciamo che possiamo definire thread le varie istanze fino a quando esse hanno delle risorse in comune. Insomma, a seconda degli elementi in comune, potremmo avere un'entità che più si avvicina al concetto di thread o di processo ""puro".
Oltretutto la gestione dei thread da parte dei sistemi operativi può essere molto differente: linux per esempio non distingue tra thread e processi (i thread vengono gestiti da funzioni di libreria), quindi in che modo potrebe esserci una differenza sostanziale?

Rifletti su questa prova:
prendiamo per esempio un programma assolutamente monocore come il SuperPI.
Cosa succede se su una macchina dotata di processore quadcore esegui 4 istanze del programma?
Se il sistema o l'hardware non fossero in grado gestire simultaneamente più processi su più core, allora avresti un netto rallentamento nell'esecuzione delle istanze di SuperPI rispetto all'esecuzione di un'istanza singola.
In caso contrario, invece, la velocità di esecuzione di ogni istanza dovrebbe essere abbastanza simile all'esecuzione di una sola istanza sulla macchina.

[Jo3]

Ti faccio un esempio molto piu pratico : prova ad immaginare un cuoco che sta curando n cibi in cottura in n pentole : ogni cibo viene posto a cuocere e quando e' pronto la pentola in cui e' viene tolta dal fuoco e il suo posto viene preso da un'altro cibo (e un'altra pentola).

Il cuoco si aggira tra i fornelli controllando ciclicamente tutte le pentole : quelle pronte, le tira giu dal fuoco, le processa (nel senso che valuta se il cibo e' mangiabile) e poi le manda alla mensa.

Prova ora ad immaginare lo stesso cuoco che rimane in attesa sulla prima pentola, fino a che il cibo al suo interno e' cotto, e poi passa alla seconda pentola, fino a che il cibo è cotto .

Mi pare ovvio che il primo sistema (multi task) e' molto piu efficace.

Prova ora ad immaginare di avere non un cuoco, ma4 4/6 cuochi : mi sembra che il processo di valutare quale cibo è pronto e processarlo, sia molto piu veloce.


la cpu in realtà non fa nient'altro che aspettare che i "cibi" siano Pronti, (pescandoli dalla coda dei processi pronti) per poi processarli

avere piu cpu (piu cuochi) significa processare molto piu velocemente i cibi.


Ovviamente la porta d'uscita alla mensa e' unica : ma visto che i cibi impiegano dai 10 ai 20 minuti per essere cotti, contro i 2/3 secondi di processo, il rischio di imbottigliamento sulla porta che da alla mensa (= le risorse quali il disco fisso) e' molto basso (statisticamente).

[Jo3]

I multi-core diventano utili nel momento in cui tali processi possiedono più di un flusso di esecuzione (threads). In questo caso i flussi eseguiti in maniera concorente vengono eseguiti in maniera realmente parallela e non a divisione di tempo come avviene nel caso di un normale single-core.

P.S : questa affermazione e' errata : i processi MONO-CORE sfruttano al meglio il multi threading (se il programma e' stato studiato pre sfruttare le caratteristiche multi threading della macchina), poiche sfruttano al meglio l'unica CPU.

I sistemi multi core invece hanno piu cpu pertanto il sistema multi thread non e' piu efficiente, visto che il multi thread e' stato pensato per sfruttare in parallelo e al meglio l'unica CPU : una volta che hai piu core, questo sistema decade.

http://it.wikipedia.org/wiki/Multithreading

Io direi che l'equazione a titolo di questa discussione vada riscritta cosi :

Multi Core = Multi Task != Multi Thread.
Mono Core = Multi Task = Multi Thread