Link alla notizia: http://www.hwupgrade.it/news/skvideo/l-importanza-di-una-architettura-parallela_33831.html

I vantaggi che derivano da una architettura parallela, nata all'inizio per i calcoli delle scene tridimensionali, hanno permesso al processo di indagine scientifica di muovere importanti passi nel corso degli anni

Click sul link per visualizzare la notizia.

be', già oggi con i sistemi multicore c'è la possibilità di avere un sistema di calcolo "parallelo" a basso costo, il problema è avere anche i software giusti (sstema operativo e applicazione) in grado di sfruttarli....

Tanto per dirne una, oggi nella maggior parte dei casi risulta più veloce un dual core da 3 GHz di un quad core da 2.5 GHz... è una condizione che va affrontata in fase di programmazione, mentre fino a oggi gli sviluppatori disoftware (per computer, intendo) hanno puntato più sulla crescita delle prestazioni dell'hardware rispetto all'ottimizzazione del software (ci girerà Crysis? :stordita: )

Tanto per dirne una, oggi nella maggior parte dei casi risulta più veloce un dual core da 3 GHz di un quad core da 2.5 GHz...

Su quali applicazioni?

Solo alcune funzioni sono parallelizzabili, mentre la maggior parte di esse rimane di tipo seriale.
La parallelizzazione di cui si parla qui è quella legata a campi specifici di simulazione dove lo sfruttamento delle risorse multiple è necessaria. Su desktop la parallelizzazione è usata per il multitasking. Purtroppo per le applicazioni desktop avere più di 2 core non ha molto senso. Word non va più veloce se hai 2 o 12 core, non perché MS non sappia parallelizzare a sufficienza, ma solo perchè le funzioni di tale applicazione (e di una miriade di altre) semplicemente non sono parallelizzabili.
Bisogna tenere anche conto di che tipo di parallelizzazione si può fare: parallelizzare su CPU multicore ha per esempio un costo in termini di overhead che sull'HW delle GPU non esiste, mentre su queste ultime il problema è la comunicazione con la CPU.

Non so' a che livello è il tuo sw, Paganetor, ma quello pesante che utilizzo per compressione/decompressione dati, video ed audio encoding, e fotoritocco spesso e volentieri sfrutta 64bit e 6 core.

Che non lo sfrutti il videogioco di turno dove nel 99% dei casi sono gpu-limited in full hd, francamente me ne infischio.
E sì che ce l'avevo il dual core 3.6 Ghz, ma un quad o six core è tutt'altra storia.

be', ovvio che con sw specifici è più facile trovare soluzioni in grado di sfruttare più core, ma vedo troppe software house (anche grosse, in ambito cad/cam/cae) che prendono in considerazione solo adesso i sistemi oeprativi a 64 bit o le cpu multicore... ovvio che in ambito di calcolo scientifico la situazione è più rosea, ma si tratta comunque di una nicchia

be', già oggi con i sistemi multicore c'è la possibilità di avere un sistema di calcolo "parallelo" a basso costo, il problema è avere anche i software giusti (sstema operativo e applicazione) in grado di sfruttarli....

Tanto per dirne una, oggi nella maggior parte dei casi risulta più veloce un dual core da 3 GHz di un quad core da 2.5 GHz... è una condizione che va affrontata in fase di programmazione, mentre fino a oggi gli sviluppatori disoftware (per computer, intendo) hanno puntato più sulla crescita delle prestazioni dell'hardware rispetto all'ottimizzazione del software (ci girerà Crysis? :stordita: )

No: quella è solo la soluzione attuale, la meno peggio dal punto di vista del software che già c'è, sul mercato da un po' e limitatamente sfruttata, sviluppata in questo modo perché evidentemente a parità di costo per il processore vanno meglio 2 o 4 core di un processore più veloce di 100Mhz.
Un sistema di calcolo parallelo te lo devi immaginare in modo diverso: allo stesso costo e magari con lo stesso numero di transistor un chip con 100 processori molto semplici a 1GHz. Il problema è che tutt'ora manca il software e non si sa bene come scrivere sw che sfrutti processori del genere (pensa al flop del processore della playstation3)

Il Cell ha un parallelismo strano, funziona perfettamente per eseguire una serie di piccole operazioni che devono essere ripetute più e più volte, come appunto nei super computer per cui è utilizzato.

Il punto è proprio che non tutto il software è parallelizzabile. Quelli di codifica video o compressione traggono vantaggio da questo, il tuo software di riproduzione audio no*, la chat non ne guadagna nulla°, il gestore di posta ben che meno...
La ricerca ha un grande guadagno dalla parallelizzazione, ma il problema è che il disco è di solito uno solo e lento quindi in pratica non guadagni nulla a meno di avere già tutto in RAM.



*Potresti gestire ogni canale su una pipeline diversa... ma la potenza attuale è tale che non cambierebbe molto.
°Potresti usare ogni contatto su una pipeline diversa... ma data l'asincronia della comunicazione, la frequenza dei messaggi, sarebbe più uno spreco di risorse dividere in così tanti sotto-processi "attivi".

Il Cell ha un parallelismo strano, funziona perfettamente per eseguire una serie di piccole operazioni che devono essere ripetute più e più volte, come appunto nei super computer per cui è utilizzato.

Il punto è proprio che non tutto il software è parallelizzabile.

Strano e che cavolo significa strano?
Cell è infarcito di idee fantastiche, in particolare i suoi processori puoi farli funzionare in parallelo ma anche in serie a scambiarsi i dati tra di loro, è un sistema molto flessibile, ma perché i sistemi paralleli non dovrebbero esserlo, è un vantaggio. Allora n'è una miriade di sistemi 'strani', già ai tempi del 68060 (intel aveva il 286 forse il 386) quello faceva esecuzione speculativa, cioè quando trovava un if eseguiva tutti e due i rami dell'if in parallelo in attesa di sapere quale dei due prendere effettivamente, non è parallelizzare un algoritmo seriale?

Non tutto il sw è parallelizzabile? A questo problema si aggiunge quello che (che sappia io) non ci sono compilatori abbastanza furi da capire quando parallelizzare il programa, quindi deve intervenire il programmatore.

Solo alcune funzioni sono parallelizzabili, mentre la maggior parte di esse rimane di tipo seriale.
La parallelizzazione di cui si parla qui è quella legata a campi specifici di simulazione dove lo sfruttamento delle risorse multiple è necessaria. Su desktop la parallelizzazione è usata per il multitasking. Purtroppo per le applicazioni desktop avere più di 2 core non ha molto senso. Word non va più veloce se hai 2 o 12 core, non perché MS non sappia parallelizzare a sufficienza, ma solo perchè le funzioni di tale applicazione (e di una miriade di altre) semplicemente non sono parallelizzabili.
Bisogna tenere anche conto di che tipo di parallelizzazione si può fare: parallelizzare su CPU multicore ha per esempio un costo in termini di overhead che sull'HW delle GPU non esiste, mentre su queste ultime il problema è la comunicazione con la CPU.

Word ha un sacco di processi che sono stati parallelizzati, per esempio, un thread per il controllo ortografico, un'altro per scrivere, ora non ricordo cos'altro ma per ora ha 8 thread che funzionano concorremente;
Il client mail.. come non si avvantaggia di un quad? solo xke é scritto male, perché quando hai 5-6k di email come il sottoscritto e si prova a fare una ricerca, stai facendo una ricerca in un database, e poter controllare 4 email per volta anziché una sicuramente riduce a un quarto il tempo, avere un browser che supporta i multicore vuol dire che un thread decodifica le immagini, un'altro renderizza il javascript... Battlefield Bad Company 2, Assassin's creed 2, star trek online, sono tutti giochi che sono usciti 6 mesi a questa parte(bc2 più veccchio) che supportano fino a 8 thread contemporanemente(e ti assicuro che bc2 la differenza la senti, tutti i calcoli che deve effettuare la fisica per ogni giocatore ve li sognate..)

Crysis supporta il multicore, solo che la grafica ancora non riesce a stargli dietro e a porre la cpu come limite alle prestazioni.. non si é visto il cpulimited su crisis nemmeno in triple sli di 480 n'altro po...

vogliamo poi mettere il fatto che la maggior parte della gente che gioca non ha come le piattaforme di test un pc che é pulito con un solo gioco installato, ha 20 programmi in background compreso antivirus che sicuramente succhia potenza???e avere 4-8 thread in totale aiuta a mantenere le performance elevate?

AHAHAAHAHAHAHAHAH

Bellissimo vedere come certa gente non capisca nulla di quello che dice eppure scrive...

Dividere in sotto-processi non vuol dire parallelizzare... questa è una cosa che si faceva anche negli anni '80 dove non esistevano CPU multi-core o con core logici.

Per esempio chairam, se devi fare un programma che estrae dei dati, li elabora e poi inserisce in una tabella di DB un dato, poi utilizzare il campo auto-incrementante o hash generato dal DBMS per inserire altri dati in un'altra tabella... come lo parallelizzi? Non puoi.

AHAHAAHAHAHAHAHAH

Bellissimo vedere come certa gente non capisca nulla di quello che dice eppure scrive...

Dividere in sotto-processi non vuol dire parallelizzare... questa è una cosa che si faceva anche negli anni '80 dove non esistevano CPU multi-core o con core logici.

Per esempio chairam, se devi fare un programma che estrae dei dati, li elabora e poi inserisce in una tabella di DB un dato, poi utilizzare il campo auto-incrementante o hash generato dal DBMS per inserire altri dati in un'altra tabella... come lo parallelizzi? Non puoi.

Dov'è che ho scritto che dividere in sotto-processi vuol dire parallelizzare? Ero d'accordo con te su 'sta cosa. Perché mi dici che non capisco? Secondo me tu no hai capito cosa ho scritto, vedi te.