Link alla notizia: http://news.hwupgrade.it/14494.html

Il CEO di AMD conferma l'intenzione di passare, tra alcuni anni, ad architetture di processore con 4 Core. Il multicore è la via del futuro

Click sul link per visualizzare la notizia.

Adesso resta solo da iniziare a rivedere il SW in chiave multithreading.

Mi sembrava di averla già letta qualche gg fa questa notizia! :(

diventeremo azionisti enel ? :mbe:

Uff mi sa ke le prossime evoluzioni tecnologiche in ambito di processori saranno solo l'aumento di core integrati... come per la corsa ai ghz, una noia mortale per l'evoluzione.

Ma ogni volta che si aggiunge un core bisognerà anche cambiare software per sfruttarlo ? Oppure assisteremo alla nascita di software in grado di riconoscere dinamicamente il numero di core e di sfruttarli in maniera adeguata ?
Perché se ogni volta che si cambia procio bisogna comprare di nuovo tutto il software ... lo stesso HW lo faccio durare almeno 5 anni !!!

Uff mi sa ke le prossime evoluzioni tecnologiche in ambito di processori saranno solo l'aumento di core integrati... come per la corsa ai ghz, una noia mortale per l'evoluzione.
Dai a me non sembra male la prospettiva che in futuro chiunque possa avere 4 CPU (o anche di più) da utilizzare sia in più applicazioni contemporaneamente, ma anche in una singola applicazione raggiungendo risultati incredibili. Sarebbe davvero bello se come dice adynak scrivessero sw in grado di riconoscere la presenza di più processori in modo dinamico, in modo da sfruttare a pieno tutta la potenza disponibile. Comunque se sviluppassero CPU con core eterogenei, sarebbe davvero un'evoluzione che porterebbe a cose oggi impensabili, una vera rivoluzione nel modo di concepire l'hw e il sw! :D

In generale no non dovrai cambiare software ogni volta che aumentano i core/processori, nel senso che il software scritto per sfruttare piu' core/processori apre N thread e poi nel caso di 2 core/processori ognuno svolgera' N/2 thread (in realta' dipende a seconda delle richieste delle altre applicazioni, ma semplifichiamo), se sono 4 core/processori ognuno svolgera' N/4 thread, tutto questo senza piu' riscrivere alcuna riga di codice ;)

diventeremo azionisti enel ? :mbe:
Eh già, però mi viene un dubbio: non era stato detto che il TDP dei dual core era lo stesso dei single? Ma soprattutto, come è possibile questo? Va bene che le due cpu condividono alcune componenti, ma comunque si parla di mettere due CPU (e anche due cache) là dove ce ne stava solo una!

Uff mi sa ke le prossime evoluzioni tecnologiche in ambito di processori saranno solo l'aumento di core integrati... come per la corsa ai ghz, una noia mortale per l'evoluzione.
Condivido pienamente.
Soprattutto sottolineo che il software dovrà continuamente essere aggiornato al frazionamento continuo dei core delle cpu, per essere sfruttato a dovere.
Cosa che con l'incremento dei MHZ almeno non avveniva! :mad:

mai sentito parlare di die shrink verso 0,065 micron? e' naturale che con l'evolversi del numero cpu si evolvera' il processo produttivo,naturalmente al diminuire del vcore necessario corrispondera' un incremento di Ampere richiesto,quindi la circuiteria delle mobo in prospettiva dovra'soddisfare requisiti di olre 200A e sicuramente i produttori di mobo approfitteranno in tal senso facendo si'che se per le mobo dualcore basti un mero aggiornamento bios x le quad occorrera' una nuova revision con finali molto piu' potenti...

ops errata corrige naturalmente x dual e quad intendo il supporto alle cpu con relativi n core!

Condivido pienamente.
Soprattutto sottolineo che il software dovrà continuamente essere aggiornato al frazionamento continuo dei core delle cpu, per essere sfruttato a dovere.
Cosa che con l'incremento dei MHZ almeno non avveniva! :mad:
Ma non e' vero!
Leggi il mio post precedente...

Per ora l'unico Sistema Operativo desktop in grado di sfruttare a dovere la presenza di più core è il vecchio, amatissimo BeOS... quindi gettiamoci tutti a capofitto su ZETA... o aspettiamo Haiku...
(fonti: yellowtab.com e haiku-os.org)

In generale no non dovrai cambiare software ogni volta che aumentano i core/processori, nel senso che il software scritto per sfruttare piu' core/processori apre N thread e poi nel caso di 2 core/processori ognuno svolgera' N/2 thread (in realta' dipende a seconda delle richieste delle altre applicazioni, ma semplifichiamo), se sono 4 core/processori ognuno svolgera' N/4 thread, tutto questo senza piu' riscrivere alcuna riga di codice ;)

Non è detto... dipende da come è fatta l'applicazione.
Se infatti usa due thread (per portare avanti due calcoli indipendenti) anche con 8 core non avrai prestazioni superiori rispetto a 2 core.
Se invece l'applicativo lancia un nuovo thread ogni volta che se ne fa richiesta, a seconda del carico avrai beneficio nell'aumentare il numero di core. Questo però lo vedo difficile da implementare in applicazioni che non siano interattive. Esempio: tempo fa ho scritto un piccolo server telnet multithread, facendo in modo che ogni nuova connessione sia gestita da un nuovo thread. In questo caso, avendo 8 core, se apro 8 connessioni queste sarebbero gestite in modo equo tra i vari core, traendone quindi beneficio. Ma se faccio solo 1 o 2 connessioni, non avrò beneficio di tutti gli altri core che non vengono utilizzati (ho semplificato in misura estrema, mi scuso per le evenutali imperfezioni che sicuramente salteranno fuori a un'occhio "allenato").

Ciao. :)

Per ora l'unico Sistema Operativo desktop in grado di sfruttare a dovere la presenza di più core è il vecchio, amatissimo BeOS... quindi gettiamoci tutti a capofitto su ZETA... o aspettiamo Haiku...
(fonti: yellowtab.com e haiku-os.org)

Be, anche gli altri derivati UNIX non sono affatto male, anzi, con linux puoi addirittura scegliere il tipo di scheduler da utilizzare (ce ne sono 3, di cui uno realtime... fantastico!).

Ciao. :)

Beh cmq si parla dei primi sample nel 2007, quindi di tempo per vedere come si evolverà la situazione ce n'è :)

EVVIVA SI CAMBIA IL CONTATORE.....:winner:
CI ALLACCIAMO DIRETTAMENTE ALLA CENTRALE:gluglu:

Ho un dubbio ma i case quanto saranno grandi???:mbe::wtf:
Oppure i proci quanto saranno piccoli??:what:

Non è detto... dipende da come è fatta l'applicazione.
Se infatti usa due thread (per portare avanti due calcoli indipendenti) anche con 8 core non avrai prestazioni superiori rispetto a 2 core.
Se invece l'applicativo lancia un nuovo thread ogni volta che se ne fa richiesta, a seconda del carico avrai beneficio nell'aumentare il numero di core. Questo però lo vedo difficile da implementare in applicazioni che non siano interattive. Esempio: tempo fa ho scritto un piccolo server telnet multithread, facendo in modo che ogni nuova connessione sia gestita da un nuovo thread. In questo caso, avendo 8 core, se apro 8 connessioni queste sarebbero gestite in modo equo tra i vari core, traendone quindi beneficio. Ma se faccio solo 1 o 2 connessioni, non avrò beneficio di tutti gli altri core che non vengono utilizzati (ho semplificato in misura estrema, mi scuso per le evenutali imperfezioni che sicuramente salteranno fuori a un'occhio "allenato").

Ciao. :)
mi hai fatto ricordare il programmino di downloading che stava scrivendo un mio amico, multithread e dinamico in un modo che non avevo mai visto... qui il problema di non avere abbastanza threads non sussiste, per il semplice motivo che essendo multiprotocollo (ftp, http, potenzialmente p2p...) multi-connessione (ho visto 32 socket per dei download http dallo stesso server, il che in realtà violerebbe le specifiche :D) e multi-fonte, e usando un thread per socket (e tenendo conto che ad es una connessione ftp di socket ne usa due, uno per i comandi uno per i dati...)... a ciò si aggiunge che l' interfaccia di suo, usa tot thread....
il punto è che in certi casi (compiti non cpu bound) le richieste della singola unità esecutiva tendono a diventare abbastanza leggere, da non richiedere certamente le prestazioni che un core può dare anche da solo, e rendere consistente la percentuale di overhead indotta dallo sfruttamento di "troppi" thread...

EVVIVA SI CAMBIA IL CONTATORE.....:winner:
CI ALLACCIAMO DIRETTAMENTE ALLA CENTRALE:gluglu:

Ho un dubbio ma i case quanto saranno grandi???:mbe::wtf:
Oppure i proci quanto saranno piccoli??:what:
ehm, non hai letto i commenti precedenti...si diceva appunto che il processo produttivo che verrà adottato nel 2007 sarà con tutta probabilità più raffinato degli attuali (0,065 micron o meno) con conseguenti consumi energetici e dissipazione, inferiori.. :rolleyes:

Perchè tanto stupore?

Il power5 ha 8 core
http://static.userland.com/weblogsCom/images/wallyswisdomwarehouseweblogscom/8XPower5MCM.jpg

Il Cell non dico che ne ha 9 ma quasi
http://static.buzzword.com/manila/staticFiles/wallyswisdomwarehouse/IBMCellChip.jpg

Non è detto... dipende da come è fatta l'applicazione.
Se infatti usa due thread (per portare avanti due calcoli indipendenti) anche con 8 core non avrai prestazioni superiori rispetto a 2 core.
Se invece l'applicativo lancia un nuovo thread ogni volta che se ne fa richiesta, a seconda del carico avrai beneficio nell'aumentare il numero di core. Questo però lo vedo difficile da implementare in applicazioni che non siano interattive. Esempio: tempo fa ho scritto un piccolo server telnet multithread, facendo in modo che ogni nuova connessione sia gestita da un nuovo thread. In questo caso, avendo 8 core, se apro 8 connessioni queste sarebbero gestite in modo equo tra i vari core, traendone quindi beneficio. Ma se faccio solo 1 o 2 connessioni, non avrò beneficio di tutti gli altri core che non vengono utilizzati (ho semplificato in misura estrema, mi scuso per le evenutali imperfezioni che sicuramente salteranno fuori a un'occhio "allenato").

Ciao. :)
Infatti ho detto in generale non deve essere riscritto il codice.
Certo che se hai solo 2 connessioni usi solo 2 core, ma se ne hai 100 usi tutti i core che hai, io sto parlando di scrivere codice che sia indipendente dal numero di core/processori e non ho detto che SEMPRE trarrai beneficio da TUTTI i core che hai.

Certo che se hai un programma che piu' di 2 cose alla volta non le deve fare allora non userai MAI piu' di 2 core, ma questo e' un altro discorso.

Please leggere bene ;)

nel caso di 2 core/processori ognuno svolgera' N/2 thread (in realta' dipende a seconda delle richieste delle altre applicazioni, ma semplifichiamo), se sono 4 core/processori ognuno svolgera' N/4 thread
beh forse dovresti chiarire meglio: ogni core potrà svolgere N/c thread si se N è divisibile per c. Supponi di avere 5 thread e 4 core, allora avrai 3 thread che vanno al 100% su tre core e 2 thread che vanno al 50% sull'altro. Per niente bilanciato. E siccome è possibile e anche abbastanza probabile che i thread debbano andare più o meno di pari passo (ad esempio nei giochi) alla fine tutti i thread andranno al 50%con spreco di potenza elaborativa.

mi sembra esagerato...
che ce ne facciamo di tutta quella potenza :mbe:
fra un po' sfrutterema le cpu al 50% e ci continueranno a rifilare cpu sempre più performanti :(
OK che è la naturale evoluzione ma che cosa pensano che siamo a qui a cambiare pc ogni 6 mesi :nonsifa: personalmente lo cambio ogni 5 anni, al max qualche upgrade, ma roba da poco...
dove andremo a finire

beh forse dovresti chiarire meglio: ogni core potrà svolgere N/c thread si se N è divisibile per c. Supponi di avere 5 thread e 4 core, allora avrai 3 thread che vanno al 100% su tre core e 2 thread che vanno al 50% sull'altro. Per niente bilanciato. E siccome è possibile e anche abbastanza probabile che i thread debbano andare più o meno di pari passo (ad esempio nei giochi) alla fine tutti i thread andranno al 50%con spreco di potenza elaborativa.
Io avevo fatto un discorso in generale che il software non va riscritto, ma molti l'hanno interpretato come un discorso sulla resa effettiva di questo approccio.

Prima di tutto non e' assolutamente detto che i thread debbano andare di pari passo, dipende un sacco da qual'e' il programma.
Prova a pensare ad un server web o ftp dove appunto ogni thread gestisce una connessione.

Secondo non e' vero che se hai 5 thread su 4 core funzia come hai detto tu, perche' dipende dallo scheduler.
In questo esempio potrebbe benissimo andare:
I primi 4 thread (1°, 2°, 3° e 4°) vanno su 4 core per un tempo X, poi il 1° cede un core al 5° thread e fai passare ancora X, poi il 2° cede al 1°, il 3° al 2°, il 4° al 3° e il 5° cede al 4°, ritrovandoti allo stato di partenza e il gioco si ripete.
Ovviamente questo in linea teorica, cioe' pensando che tutti e 5 i thread hanno la stessa priorita' e senza nessun altro processo che disturba il calcolo.

Quindi come vedi ogni core puo' sempre lavorare senza sprecare proprio nulla.
Tutto dipende dal software usato e dalle politiche di scheduling.

Aspetta un attimo tu parli del caso di cache condivisa forse, altrimenti non direi che è possibile un approccio del genere. E se la cache è condivisa è anche molto meno efficente. vabbè che se stiamo su processori intel con due mega di cache allora non cambia più di tanto :)

Aspetta un attimo tu parli del caso di cache condivisa forse, altrimenti non direi che è possibile un approccio del genere. E se la cache è condivisa è anche molto meno efficente. vabbè che se stiamo su processori intel con due mega di cache allora non cambia più di tanto :)
Io credo che il mio metodo sia applicabile anche con processori a cache non condivisa, pero' porterebbe ad avere un carico/scarico di cache esagerato e forse perderesti prestazioni, ma non so bisognerebbe fare delle prove :)

Aspetta un attimo tu parli del caso di cache condivisa forse, altrimenti non direi che è possibile un approccio del genere.
Se ne è già parlato tempo fa. Un approccio a cache non condivisa non è molto diverso da una configurazione SMP (symmetric multi-processor) che è usata correntemente nei sistemi server. I compilatori per queste architetture (e ci sono librerie specifiche per i sistemi multiprocessore, come le MPI) sono sicuramente ottimizzati per ridurre i cache miss e i periodi di inattività dei processori.

In questo esempio potrebbe benissimo andare:
I primi 4 thread (1°, 2°, 3° e 4°) vanno su 4 core per un tempo X, poi il 1° cede un core al 5° thread e fai passare ancora X, poi il 2° cede al 1°, il 3° al 2°, il 4° al 3° e il 5° cede al 4°, ritrovandoti allo stato di partenza e il gioco si ripete.
Ovviamente questo in linea teorica, cioe' pensando che tutti e 5 i thread hanno la stessa priorita' e senza nessun altro processo che disturba il calcolo.

Quindi come vedi ogni core puo' sempre lavorare senza sprecare proprio nulla.
Tutto dipende dal software usato e dalle politiche di scheduling.
Non mi torna una cosa: mentre sono attivi 4 thread, il 5° che fa, aspetta pazientemente? Facciamo conto che devi esegure, invece che delle connessioni indipendenti l'una dall'altra, un programma di colcolo che ha bisogno di fare 1M di operazioni in un determinato ordine, dato dalle regole delle operazioni matematiche; un buon metodo per far sì che il programma sfrutti tutti i possibili core presenti è suddividere ogni gruppo di operazioni a uguale priorità in un unico thread, in modo che il processore porti avanti i calcoli in modo separato e quindi, con la presenza di più core, più rapido. Però se un thread per un certo X tempo non procede perchè non è stato assegnato ad alcuna CPU, anche se nel frattempo gli altri thread vanno come schegge, molto probabilmente dovranno attendere che sia passato X tempo e che siano concluse le operazioni sul thread rimasto inattivo, sprecando le risorse e quasi annullando i vantaggi di avere più di un core.
E' solo un'idea che mi è venuta leggendo il commento, molto probabilmete ci sono madarnali errori, ma il concetto di fondo spero che si sia capito.

mai sentito parlare di die shrink verso 0,065 micron? e' naturale che con l'evolversi del numero cpu si evolvera' il processo produttivo,naturalmente al diminuire del vcore necessario corrispondera' un incremento di Ampere richiesto,quindi la circuiteria delle mobo in prospettiva dovra'soddisfare requisiti di olre 200A e sicuramente i produttori di mobo approfitteranno in tal senso facendo si'che se per le mobo dualcore basti un mero aggiornamento bios x le quad occorrera' una nuova revision con finali molto piu' potenti...
Si ma mi pare che gli Opteron DC e gli Athlon 64 DC (e anche gli Intel) siano ancora a 0,09 micron, e non a 0,065. Quindi non ho ancora capito come mai un processore a 0,13 consumi come 2 a 0,09, tutto qui. Poi per i quad core si vedrà, intanto mi bastava chiarire questo punto.

Non mi torna una cosa: mentre sono attivi 4 thread, il 5° che fa, aspetta pazientemente? Facciamo conto che devi esegure, invece che delle connessioni indipendenti l'una dall'altra, un programma di colcolo che ha bisogno di fare 1M di operazioni in un determinato ordine, dato dalle regole delle operazioni matematiche; un buon metodo per far sì che il programma sfrutti tutti i possibili core presenti è suddividere ogni gruppo di operazioni a uguale priorità in un unico thread, in modo che il processore porti avanti i calcoli in modo separato e quindi, con la presenza di più core, più rapido. Però se un thread per un certo X tempo non procede perchè non è stato assegnato ad alcuna CPU, anche se nel frattempo gli altri thread vanno come schegge, molto probabilmente dovranno attendere che sia passato X tempo e che siano concluse le operazioni sul thread rimasto inattivo, sprecando le risorse e quasi annullando i vantaggi di avere più di un core.
E' solo un'idea che mi è venuta leggendo il commento, molto probabilmete ci sono madarnali errori, ma il concetto di fondo spero che si sia capito.
Non ho ben chiaro il tuo esempio: se tutte le operazioni che hanno medesima priorita' sono su un thread solo non bisogna aspettare che questo thread finisca il calcolo per passare alle operazioni di priorita' piu' bassa?

Fai un esempio pratico che forse non ho capito bene io...

Adesso resta solo da iniziare a rivedere il SW in chiave multithreading.
Hai detto niente! :eek: E' un lavoro non facile, e tra l'altro non tutte le applicazioni si possono "parallelizzare" in modo da sfruttare più di un core...

Infatti ho detto in generale non deve essere riscritto il codice.
Certo che se hai solo 2 connessioni usi solo 2 core, ma se ne hai 100 usi tutti i core che hai, io sto parlando di scrivere codice che sia indipendente dal numero di core/processori e non ho detto che SEMPRE trarrai beneficio da TUTTI i core che hai.

Certo che se hai un programma che piu' di 2 cose alla volta non le deve fare allora non userai MAI piu' di 2 core, ma questo e' un altro discorso.

Please leggere bene ;)

Ciao, dal tuo commento mi pareva di aver capito diversamente. :)

Ciao. :)

mi hai fatto ricordare il programmino di downloading che stava scrivendo un mio amico, multithread e dinamico in un modo che non avevo mai visto... qui il problema di non avere abbastanza threads non sussiste, per il semplice motivo che essendo multiprotocollo (ftp, http, potenzialmente p2p...) multi-connessione (ho visto 32 socket per dei download http dallo stesso server, il che in realtà violerebbe le specifiche :D) e multi-fonte, e usando un thread per socket (e tenendo conto che ad es una connessione ftp di socket ne usa due, uno per i comandi uno per i dati...)... a ciò si aggiunge che l' interfaccia di suo, usa tot thread....
il punto è che in certi casi (compiti non cpu bound) le richieste della singola unità esecutiva tendono a diventare abbastanza leggere, da non richiedere certamente le prestazioni che un core può dare anche da solo, e rendere consistente la percentuale di overhead indotta dallo sfruttamento di "troppi" thread...

Giusto... spesso anche una sola CPU per questi compiti è più che sovrabbondante! ;)

Ciao. :)

Non ho ben chiaro il tuo esempio: se tutte le operazioni che hanno medesima priorita' sono su un thread solo non bisogna aspettare che questo thread finisca il calcolo per passare alle operazioni di priorita' piu' bassa?

Fai un esempio pratico che forse non ho capito bene io...
L'esempio che avevo in mente è un calcolo come (3+2-6)+(4*5)+(2*3*4)+(5/3)-(6*7)
Se vogliamo che il calcolo non venga eseguito da una stessa CPU lo dividiamo in thread, per esempio le parti in parentesi, che sono composte da operazioni con la stessa priorità, possono comodamente costituire un thread; abbiamo dunque 5 thread. Mettiamo di avere una CPU quad core, allora se i thread fossero divisi come dicevi, ovvero i primi i primi quattro affidati ciascuno a una delle CPU e il quinto in attesa di un tempo X, anche se i calcoli sui 4 thread si svolgono rapidamente il risultato finale tarderà comunque ad arrivare perchè si deve aspettare il tempo X e affinchè inizi il calcolo sul quinto thread e il tempo perchè esso sia concluso. Solo allora sarà possibile calcolare il risultato completo sommando i risultati dei 5 thread.
Questo è chiaramente solo un esempio, acquista significato solo se ogni thread fosse molto più complesso e lungo da svolgere.

L'esempio che avevo in mente è un calcolo come (3+2-6)+(4*5)+(2*3*4)+(5/3)-(6*7)
Se vogliamo che il calcolo non venga eseguito da una stessa CPU lo dividiamo in thread, per esempio le parti in parentesi, che sono composte da operazioni con la stessa priorità, possono comodamente costituire un thread; abbiamo dunque 5 thread. Mettiamo di avere una CPU quad core, allora se i thread fossero divisi come dicevi, ovvero i primi i primi quattro affidati ciascuno a una delle CPU e il quinto in attesa di un tempo X, anche se i calcoli sui 4 thread si svolgono rapidamente il risultato finale tarderà comunque ad arrivare perchè si deve aspettare il tempo X e affinchè inizi il calcolo sul quinto thread e il tempo perchè esso sia concluso. Solo allora sarà possibile calcolare il risultato completo sommando i risultati dei 5 thread.
Questo è chiaramente solo un esempio, acquista significato solo se ogni thread fosse molto più complesso e lungo da svolgere.
Ah ok ora e' molto piu' chiaro.
Comunque il mio esempio era riferito a thread che sono indipendenti dall'andamento dei calcoli tra di loro e ad ogni modo anche nel tuo esempio se ci sono calcoli molto pesanti e X ovviamente e' piccolo funziona abbastanza bene lo stesso.

Hai detto niente! :eek: E' un lavoro non facile, e tra l'altro non tutte le applicazioni si possono "parallelizzare" in modo da sfruttare più di un core...
Ho già trovato commenti tipo queste diverse volte e ci ho sempre creduto sulla fiducia; tuttavia mi piacerebbe capire quali e soprattutto quante sono le applicazioni assolutamente impossibili da parallelizzare. Giusto per capire quanto un'architettura multicore possa essere utile in futuro..

Il MAME. :D

In generale un emulatore, un compilatore (si può "parallelizzare" fino a un certo punto), applicazioni di tipo "office" (es: ricerca e sostituzione di una stringa, controllo sintattico ecc.), un gioco (solo alcune parti lo sono, almeno per ora), le modifiche a un database (le query possono essere eseguite "in parallelo"), ecc.

Aspetta, non so se ho capito bene:
-Si possono parallelizzare in parte, un emulatore o un compilatore, un gioco.
-Si posono parallellizzare completamente le query sql a un database.
Ho capito bene? :wtf:

Un emulatore è difficilmente parallelizzabile, perché l'emulazione di un processore (ma si può estendere anche alla sottosezione video e audio) è un processo strettamente sequenziale, il cui risultato dipende dai calcoli precedenti.
Nel caso dell'emulazione di un sistema con più processori, si potrebbe pensare di far emulare ciascuno di essi da un apposito processore, ma ciò quasi sempre non è fattibile perché si va incontro a problemi di sincronizzazione fra di essi. Questo è il motivo per cui il MAME che ho citato (ma il discorso vale anche per tanti altri sistemi; ad esempio l'Amiga, che ha una sola CPU ma tanti chip custom che fanno tanti lavori diversi, richiede un'emulazione precisa e sincronizzata al ciclo di clock) non sarà mai parallelizzabile: l'accuratezza dell'emulazione del sistema è il suo obiettivo primario, e questo comporta che l'interleaving fra i vari processori / chip sia "molto stretto".

Un compilatore si può parallelizzare nella misura in cui i sorgenti non presentino dipendenze fra di essi, e quindi si può pensare di compilarli indipendentemente; per quelli che presentano dipendenze, si deve ovviamente attenderne la compilazione. Il problema è che la dipendenza dei sorgenti (dal punto di vista del compilatore) si presenta molto spesso.

Per quanto riguarda i giochi, attualmente la tendenza è quella di elaborare l'audio in un thread a parte rispetto alla fase di calcolo della fisica / IA, aggiornamento della scena, invio della scena alla GPU, che è un'operazione strettamente sequenziale (il passo successivo dipende da quello precedente). Probabilmente è possibile pensare di parallelizzare il calcolo della fisica /IA e l'aggiornamento della scena, ma non conosco le problematiche che ciò comporta: attualmente mi sembra che nessun engine lo faccia, per cui penso che non sia un'operazione fattile o comunque facile da risolvere.

Infine per quanto riguarda le query e il database, non è la query di per sé che è possibile parallelizzare, quanto le richieste di query che arrivano all'engine SQL, che è possibile smistare ai processori disponibili. Questo perché si tratta di operazioni di sola lettura, che quindi non alterando i dati del database non richiedono operazioni di locking e l'uso di semafori / mutex.

In Oracle, per la modica cifra di (mi pare) 100.000 $ è possibile acquistare l'opzione per poter parallelizzare le singole query (supposto che siano sufficientemente complesse)...

Per quanto riguarda i giochi, attualmente la tendenza è quella di elaborare l'audio in un thread a parte rispetto alla fase di calcolo della fisica / IA, aggiornamento della scena, invio della scena alla GPU, che è un'operazione strettamente sequenziale (il passo successivo dipende da quello precedente). Probabilmente è possibile pensare di parallelizzare il calcolo della fisica /IA e l'aggiornamento della scena, ma non conosco le problematiche che ciò comporta: attualmente mi sembra che nessun engine lo faccia, per cui penso che non sia un'operazione fattile o comunque facile da risolvere.
... se non ricordo male quel che diceva poco tempo fa fek, anche la parte di rendering potrebbe stare in un thread a se stante
quindi restrebbero audio+render+fisica&interazione, il che avrebbe forse senso in quanto il renderer maneggia un set di dati (vertici, texture, comandi per la gpu) che e' un proxy di quello completo e non quello completo (mondo, modelli 3d e "attori", campi di forza ecc)... :)
Infine per quanto riguarda le query e il database, non è la query di per sé che è possibile parallelizzare, quanto le richieste di query che arrivano all'engine SQL, che è possibile smistare ai processori disponibili. Questo perché si tratta di operazioni di sola lettura, che quindi non alterando i dati del database non richiedono operazioni di locking e l'uso di semafori / mutex.
esatto... in questo caso dovrebbe bastare una buona progettazione del programma, di modo che il multithreading consenta di accettare piu' query in ingresso e far partire l' elaborazione di ognuna in modo indipendente dalle altre (funzionamento asincrono - non si aspetta che un' operazione sia conclusa per iniziarne una nuova e/o continuare l' elaborazione) ;)
le cose si complicano quando gli accessi in lettura si mescolano con degli accessi in scrittura (aggiornamento di un record che altri ) ... allora tocca serializzare l' accesso per quel record in modo che le letture successive siano bloccate fintanto che l' aggiornamento del record non e' concluso: infatti procedure in lettura con timestamp successivo a quello della scrittura, DEVONO trovare il valore aggiornato del record, se ottengono quello vecchio il dato non e' consistente
questo per le operazioni "logiche" compiute su un archivio... bisogna pensare che un DB avra` da manipolare i suoi dati utilizzando dei file su disco: per fare questo dovra' appoggiarsi al livello filesystem del sistema operativo (e cercare di ottenere aggiornamenti il piu` possibile "atomici" per quello che esso consente) oppure, possibilita`scelta per quanto ne so in vari casi, reimplementare ex novo tale livello

... se non ricordo male quel che diceva poco tempo fa fek, anche la parte di rendering potrebbe stare in un thread a se stante
Un gioco si presta relativamente bene alla parallelizzazione, dal momento che ha vari jobs separati, alcuni dei quali (come calcolo della fisica, della AI, animazione) possono essere smistati su più core. Questo però porta a parecchi problemi dal punto di vista dell'architettura, come la sincronizzazione dei vari jobs, l'assegnazione delle risorse (si rischiano scatti o audio che gracchia, ad esempio), politiche di scheduling etc.
Visto il costo e le risorse necessarie a creare un motore per singolo processore, non è il caso di creare engine multicore fino a quando il mercato non lo richiede ;)

le cose si complicano quando gli accessi in lettura si mescolano con degli accessi in scrittura (aggiornamento di un record che altri ) ... allora tocca serializzare l' accesso per quel record in modo che le letture successive siano bloccate fintanto che l' aggiornamento del record non e' concluso: infatti procedure in lettura con timestamp successivo a quello della scrittura, DEVONO trovare il valore aggiornato del record, se ottengono quello vecchio il dato non e' consistente
Su queste problematiche c'è una quantità di materiale sconfinato... esistono diverse politiche di scheduling via via più complesse per massimizzare il numero di query parallele gestite sullo stesso sistema (esempio, conflict serializability, 2 phase lock serializability etc.). Nel caso di letture e di scritture è possibile usare tecniche di lock gerarchico fino a livello di singolo record, con diversi permessi di lettura e scrittura (esempio, sono possibili più reader per la stessa risorsa, ma un solo un writer). In genere poi i grandi sistemi sono distribuiti, e quindi ci sono tutta una serie di algoritmi studiati per garantire la sincronizzazione e la consistenza di tutte le fasi della transazione.
Penso che nel campo dei DBMS i multicore saranno ben sfruttati, dal momento che già ora si usano macchine multiprocessore, o sistemi formati da più macchine che lavorano in parallelo.

In Oracle, per la modica cifra di (mi pare) 100.000 $ è possibile acquistare l'opzione per poter parallelizzare le singole query (supposto che siano sufficientemente complesse)...
:eek: si fanno pagare un sacco di soldi... :(

Per sufficientemente complesse cosa intendono? Che ci siano diverse join? :D

Comunque è difficile "parallelizzare" una query, anche complessa / con tante join: spesso per "andare avanti" è necessario conoscere i risultati precedenti...

Non mi dedico più ai giochi da parecchio tempo, quindi non conosco le tendenze attuali nello sviluppo delle varie fasi. Ai tempi (una dozzina d'anni fa) ricordo che calcolo della fisica, IA e rendering erano strettamente sequenziali e dipendenti l'uno dall'altro. :p

Quanto alle query, effettivamente letteratura in materia non manca di certo. :)
Trovo interessante l'approccio ottimistico di InterBase (e FireBird, il suo "erede" open source), che apre una transazione per qualunque operazione (anche in lettura: ogni record ha un "versioning" legato strettamente alla transazione), decidendo al commit della prima transazione che modifica dei record i cambiamenti effettuati, e "bloccando" (generando un'eccezione / fallimento) tutti i tentativi di modifica successivi per gli stessi record.

Ovviamente uno si compra l'opzione solo se il gioco vale la candela, per esempio query complesse possono servire per fare analisi tipo data mining e credo siano obbligatorie per fare il data warehousing (penso al roll up, drill down o al data cube, che sono query pesantissime)...