Processori e nuovi processi produttivi: una via insidiosa

[Dreadnought]

Originariamente inviato da ShadowX84
La domanda che mi pongo è la seguente: io sono un pincopallino qualunque che commenta news su questo sito e dico la mia opinione su certe cose;
quelli che lavorano alla Intel invece sono sicuramente tutti Dott.Ing. da 110 e lode, e quindi se hanno operato tali scelte avranno avuto i loro buoni motivi giusto??...si...giusto!!...ma quali potrebbero essere questi buoni motivi???Mha...

noi non dobbiamo fare i conti con i tempi, la concorrenza, i brevetti, i commerciali, i PR, gli NDA...

Non ho capito molto bene quello che volevi dire, puoi rispiegarmelo??
Da quello che ho capito tu dici che 0,13um è la lunghezza d'onda usata per incidere il silicio.
Se intendevi dire questo devo correggerti in quanto la lunghezza d'onda utilizzata per fare "incisioni" a 130nm (0,13 um che dir si voglia) è di 248nm (0,24 micron), mentre a 90nm si ricorre a lunghezze d'onda di 193nm.

Se volevi dire tutt'altra cosa ti chiedo scusa!

hummm
come fai a incidere a 90nm con 193nm di lunghezza d'onda?

vabeh a aprte questo, ho letto qua e là che per lo 0.13 e lo 0.09 non si usano più gli EUV (ultravioletti corti) ma usano raggi-X combinati con UV perchè le lunghezze d'onda solite non sono abbastanz adefinite (penso ci siano effetti tipo abberrazioni date da interferenza)

Ehm...mi potresti scrivere il link, mi interesserebbe molto informarmi a riguardo!!

bye bye!

mi pare sia questo (ho cercato underwater lithograpy su google
http://www.reed-electronics.com/semi...ndustryid=3030

poi ho trovato questo.
http://www.de.afrl.af.mil/APT/iq3-4.chtm.html

edit: interessante questo link:
http://www.iastate.edu/~ch_e/faculty...ithography.ppt

[Italian Stallio]

Con la riduzione della minimum feature size (gli 0.13,0.09 um) i problemi maggiori si hanno nei livelli di metallizazzione. É inutile fare un livello logico piccolo piccolo se poi le connessioni nel lext layer sono enormi. Oltretutto, sono proprio i vari livelli di metallizazzione che scaldano.

Putroppo il problema con il 0.09 é l'aspect ratio del metallo. L'aspect ratio é un numerino che ti indica il rapporto tra lo spessore della connessione e la larghezza minima d'incisione. Putroppo si sono raggiunti i limiti fisici..... Quindi é inutile metter sul chip un conduttore di metallo spesso 90 nm, se poi le proprietá del metallo ti permettono di fare solo un buco da 400nm (numero esagerato).

E c'é molto di piú.... se volete saperne di piú, leggetevi il rapporto ITRS sulle connessioni e il processo di fabbricazione.

Quindi é troppo facile dire "facciamo il die un po' piú grande" o "meglio cambiare l'architettura". Troppo facile.....

[ShadowX84]

Per quanto riguarda la lunghezza d'onda utizzata per incidere, su internet si dovrebbe trovare delle informazioni abbastanza precise, adesso guardo se ti trovo qualcosa e poi ti faccio sapere!

[ShadowX84]

Ho già trovato qualcosa, direttamente qui su Hwupgrade;
Si tratta della recenzione dei primi Prescott, ecco il link:

http://www.hwupgrade.it/articoli/971/2.html

Le informazioni che ti dicevo sono circa a metà pagina dopo la tabella riassuntiva delle caratteristiche dei processori!

Bye bye!

[lucusta]

No, non intendevo una cpu a moduli ripetuti, che altro non sarebbe che una multi-core nello stesso die; intendevo una classica cpu, veloce ed efficente (pipeline corte, prediction facile, e quantitativo di caches adeguato), ma semplice, della potenza di un P3 1ghz.
E' il concetto del pc che deve cambiare: riuscire a modulare la potenza rispetto alle esigenze, aumentando solo di quanti moduli necessitano.
Il concetto e' simile a quello adottato da ati con le GPU, ed e'simile al classico multiprocessore, dove pero' la comunicazione tra' due cpu e' limitata dalla banda della comunicazione adottata.
nella pratica delle cpu piccole e poco potenti, che si possano aggregare per farne una sola piu' complessa e potente.. un core P3 a 0.09 sarebbe un quadratino di 25mm2, mettici controller verso le altre cpu ed il sistema e logica di assemblamento dell'informazione e non si superano i 30mm2, usa lo stesso package come socket per attaccarlo alle altre cpu e alla scheda madre, ed un sistema di raffreddamento modulare, e si riuscirebbe a fare un'architettura ben piu' moderna (oltre al fatto che cpu' piccole e che consumanopoco aprirebbero il mercato anche ad altri tipi di dispositivi).

[Dreadnought]

Originariamente inviato da ShadowX84
Ho già trovato qualcosa, direttamente qui su Hwupgrade;
Si tratta della recenzione dei primi Prescott, ecco il link:

http://www.hwupgrade.it/articoli/971/2.html

Le informazioni che ti dicevo sono circa a metà pagina dopo la tabella riassuntiva delle caratteristiche dei processori!

Eh si ho visto ga io ieri che parlavano di litografie a 193nm per produrre a 90nm, ma non ho capito perchè, probabilmente perchè il gate è quello che rimane (così come dalla presentazione PPT che ho postato) mentre la litografia lavora in negativo quindi 193nm è la grandezza del solco attorno al gate.

x italian stallio: guarda la presentazione PPT verso il fondo, ci sono delle immagini a scansione interessanti su quello che dici.

[ShadowX84]

Piacerebbe anche a me una cosa di quel genere....

...ma onestamente credo che abbiamo più possibilità di andare io e te a piedi sulla luna, che di vedere Intel e AMD e company che si mettono a fare cose del genere!!

Bye!

[lucusta]

purtroppo hai pienamente ragione.. non e' remunerativo pensare con logica in questo mercato.
come non sarebbe remunerativo vendere CPU sbloccate in cui si dichiara il consumo ad un clock prefissato:
ti vendo una cpu che a 1ghz consuma 25,30,35,40w, e te la faccio pagare sempre meno per quanto consuma di piu', poi se tu la spingi oltre il clock non hai diritto alla garanzia, e per saperlo ho una eprom a sola lettura che mi indica i parametri maggiori a cui e' stata mandata.

[xeal]

X lucusta:

Quello che dici sembra una via di mezzo tra multiprocessore e multicore: invece di aggiungere cpu aggiungi core semplici e dai consumi ridotti su una stessa base, per modularne la potenza di calcolo, giusto? In questi termini, credo che sia molto difficile, se non impossibile, da realizzare: utilizzare un solo socket potrebbe essere impossibile, specie se integri molti memory controller per velocizzare il sistema. Inoltre, in alcuni ambiti serve molta potenza, per cui sarebbe preferibile avere 8 processori a 2-3 ghz e comlessi come quelli attuali, piuttosto che 8 da 1 ghz, e aumentare il numero di processori potrebbe risultare inutile, dipende tutto dal grado di parallelismo delle applicazioni che utilizzi.

Poi, quello che dici in parte assomiglia all'architettura dei sistemi multiprocessore opteron: hai processori potenti che gestiscono autonomamente la memoria e con basse latenze, grazie al controller integrato (e riduci un collo di bottiglia), e che comunicano tra di loro tramite il bus hyper transport dedicato (e riduci un altro collo di bottiglia). Credo che la strada più facile da percorrere sia quella di un multiprocessore tradizionale, eventualmente multicore, cercando di ridurre il più possibile i colli di bottiglia. Questa strada può consentire di ottenere risultati eccellenti anche con frequenze ridotte, ma non credo che si possa scendere troppo.

Infine, comunque si cerchi di ottenere modularità e scalabilità delle risorse di calcolo mediante "varianti" dei sistemi concorrenti, servono applicazioni fortissimamente ottimizzate. E anche con queste, a volte "moduli" da 1 ghz (con architettura non particolarmente ottimizzata, ovvio che se parli di a64 o centrino già le cose migliorano) potrebbero non bastare. Attualmente, con la maggior parte dei programmi desktop, il word processor e il giochino stupido di cui parli in primis, un sistema come quello che proponi, con 80000 "mattoncini" p2 da un ghz andrebbe esattamente come un sistema con una sola cpu p2 da 1ghz, quindi non si migliorerebbe affatto la situazione. Noteresti differenze solo con 80000 processi o thread (che non dipendano gli uni dagli altri) in esecuzione contemporanea. E questo è il vero limite all'introduzione dei multicore nei desktop. E anche con le applicazioni ottimizzate, n moduli semplici potrebbero non bastare ed essere necessari n-k moduli più complessi e veloci.


Quello del software ottimizzato per l'esecuzione parallela massiccia non è un problema banale: oggi "a manina" si può fare tutto e il contrario di tutto, ci sono linguaggi e paradigmi di programmazione che cercano di facilitare il tutto (vedi linda e derivati) e consentono, ad esempio, di spostare, in un sistema distribuito, un processo da un processore troppo occupato ad uno meno (principalmente sfruttando gli idle), ma si tratta di soluzioni che richiedono comunque un overhead di programmazione, tempi e costi probabilmente inaccettabili/fuori luogo per sistemi desktop tradizionali. La svolta sarebbe poter risolvere il problema al livello del compilatore, in modo da sgravare il programmatore dal compito di gestire la parallelizzazione dei calcoli, poichè il compilatore riesce a individuare le parti che si possono eseguire in parallelo (l'importanza di una soluzione del genere si capisce meglio pensando ad un supercomputer con interconnessioni programmabili, ovvero con sottosistemi di processori definibili e ridefinibili a piacimento e assegnabili a compiti specifici, dove, nell'ambito dei processori che tu hai a disposizione, puoi e soprattutto devi decidere quali usare per fare cosa e quali processori comunicano tra di loro direttamente, stiamo parlando ovviamente di multiuser). Purtroppo siamo ancora molto lontani...

[cdimauro]

Francamente penso che il miglior compilatore che sia in grado di distribuire il carico computazionale nei sistemi distribuiti sia il cervello umano.

Quanto al discorso in generale, c'è da considerare che non sono pochi i casi in cui non è possibile "parallelizzare" l'esecuzione di un algoritmo. Ecco perché scalare in frequenza serve (cercando di mantenere l'IPC): comunque si hanno dei miglioramenti con questi algoritmi, che dalla presenza di 1 o più CPU addizionali non se ne farebbero niente...

[lucam78]

Originariamente inviato da Marino5
credo che la soluzione sia da cercare in diversi tipi di materiali prima e di un radicale cambio di architettura poi.. ovvio che questo costa parecchio e di conseguenza è altrettatnto ovvio che i grandi produttori cercano quanto più possibile di sfruttare le attuali tecnologie..

quoto pienamente credo che da adesso in poi dovranno impiegare piu risorse nella ricerca di nuovi materiali per costruire nuove cpu oramai credo che siamo arrivati alla fine delle cpu in silicio

cmq imho i casi sono 2
1)si cambia materiale con un potere dissipativo maggiore del silicio e si sale di frequenza

2)si studia una nuova architettura per le future cpu in modo da dare risultati maggiori anche a frequenze minori e imho questa sarà la vera innovazione

[xeal]

Originariamente inviato da cdimauro
Francamente penso che il miglior compilatore che sia in grado di distribuire il carico computazionale nei sistemi distribuiti sia il cervello umano.

Indubbiamente, in fondo il computer più potente al mondo siamo noi. Però raggiungere una certa automazione in certi ambiti può favorire non poco la diffusione di sistemi di calcolo distribuiti, allo stesso modo in cui l'introduzione di compilatori in grado di produrre codice eseguibile con lo stesso grado di ottimizzazione di quello prodotto da un programmatore di media esperienza (comunque lontano dai risultati di un programmatore assembly esperto) insieme alla diffusione crescente di maggiori risorse tecnologiche a costi abbordabili ha accelerato notevolmente i tempi di produzione di un applicativo. Se dovessimo ragionare ancora in termini del mezzo byte da risparmiare e di come distribuire i dati tra digit e zonatura probabilmente questo forum non esisterebbe o non sarebbe a disposizione di tutti.

In sistemi come quello che ho descritto possono volerci mesi per capire dove mettere le mani, prima di cominciare a lavorare sul serio. Questo discorso potrebbe investire la vita di tutti nel momento in cui si premesse sul serio l'acceleratore verso l'ubiquitous computing (domotica e compagnia bella), con la necessità di trovare middleware e nuovi schemi di programmazione ad agenti in grado di far collaborare "strumenti" anche molto diversi, dato che l'obiettivo di fondo è distribuire il più possibile il carico di lavoro tra le varie "entità". Si può pensare, ad esempio, ad una parte del sistema di controllo di una casa futuristica che gestisce una lavatrice e una lavastoviglie, inviando degli agenti "simili" ai due elettrodomestici, per poi differenziarsi mediante apprendimento delle caratteristiche specifiche dello strumento da gestire (fondendo il modello di coordinazione ad agenda con quello per specializzazione), oppure ancora ad un robot che fa da guida in un museo, dotato di funzionalità di movimento e interazione di base, che entrando in una certa sala "scarica" le informazioni generali sulla distribuzione degli oggetti e sul percorso da seguire, insieme ad un qualche agente che potrebbe settare dei parametri particolari relativi al movimento del robot, effettuando ad esempio una taratura rapida sulle caratteristiche della pavimentazione, cosa che potrebbe essere in grado di fare da solo ma più lentamente, mentre passando vicino alle varie opere il robot preleverebbe dal sistema le informazioni da riferire ai visitatori (ok, sto divagando rispetto ai compiti di un compilatore, però una certa automazione nelle metodologie di sviluppo del software di gestione, le quali evitino di dover studiare "a parte" ogni minimo dettaglio, a qualsiasi livello, gioverebbero parecchio).

Ciao a tutti.

[Dreadnought]

Originariamente inviato da lucam78
cmq imho i casi sono 2
1)si cambia materiale con un potere dissipativo maggiore del silicio e si sale di frequenza

Ma guarda che in una CPU i silicio ha una percentuale minima, è solo l'ultimo strato fine, il restante 80% di spessore è tutto dovuto ai vari livelli di metallizzazione.

Guarda qualche foto in questo ottimo articolo di lithium
http://www.lithium.it/articolo.asp?code=57&user=249

2)si studia una nuova architettura per le future cpu in modo da dare risultati maggiori anche a frequenze minori e imho questa sarà la vera innovazione

Stanno lavorando sui chip ottici per quello
Sia intel in israele che STmicro in italia, + altri come IBM.

[cdimauro]

x xeal: forse dovevo spiegarmi meglio. Intendevo che le migliori soluzioni distribuite sono quelle pensate e realizzate da esseri umani. Se devo realizzare un sistema distribuito per una certa applicazione, non c'è niente di meglio di una soluzione custom, piuttosto che affidarsi agli automatismi offerti dagli attuali sistemi distribuiti. Lapalissiano, insomma.

[xeal]

Chiaramente ci vorrà sempre l'intervento umano, però un qualche automatismo di base, migliore di quelli attuali, sarebbe d'aiuto per sveltire il lavoro. Intanto servirebbe qualcosa che consenta di sfruttare decentemente le soluzioni che abbiamo senza dover perdere il sonno su ogni minimo dettaglio, poi può darsi che le soluzioni di domani ci consentano di progettare più rapidamente anche soluzioni custom, l'importante è non esagerare e farci mandare in pensione dalle nostre stesse "creature"

Di questo passo mi sa che torniamo al discorso delle macchine che lavorano per noi mentre ce la spassiamo, fino alla ribellione e alla creazione di matrix

Ciao

[cdimauro]

Gli automatismi indubbiamente servono, anzi: più velocemente si può fare un lavoro, meglio è, chiaramente.
Soltanto che ho intenzione di creare un cluster per delle applicazioni specifiche, preferisco che sia l'applicazione stessa che ho scritto a distribuire il carico di lavoro, sapendo già quali sono gli obiettivi da raggiungere. Tutto qua.

[xeal]

Beh, molte cose probabilmente si dovranno sempre progettare a mano, poi, oggi, al massimo si possono usare linguaggi più o meno sperimentali (vedi linda e derivati) che ti consentono di specificare un modello di coordinazione per le varie parti senza scendere troppo di livello e di trattare tuple di dati come parti di codice eseguibile, che include funzioni e agenti mobili, oppure di spostare in maniera abbastanza automatica un processo da una macchina all'altra, nei momenti di maggior lavoro.

Io mi riferivo principalmente a questi linguaggi, e più ancora a quelli (ce n'è uno in particolare, non ricordo il nome, interpretato, che si usa a livello universitario per sperimentare nuove soluzioni) che ti consentono di specificare delle singole istruzioni da eseguire in parallelo, su più processori (col rischio di fare casini): oggi, con un linguaggio di questo tipo devi porre molta attenzione nello scegliere le istruzioni, se proprio lo vuoi fare, ma se ci fosse un compilatore in grado di individuarle da solo con una certa precisione, sarebbe comodo. Per fare un esempio banale, immagina di avere una funzione che a un certo punto valuta tre espressioni abbastanza complesse, poste in or: il nostro bel compilatore "intelligente" (e per non incasinare tutto, tenendo conto di eventuali effetti collaterali nelle espressioni dovrebbe esserlo molto) potrebbe decidere di delegare il calcolo di ciascuna espressione ad un processore diverso (immaginando di avere un sistema praticamente privo di colli di bottiglia), quindi il primo risultato "vero" viene spostato sul processore che dovrà eseguire la prima istruzione successiva che necessita di quel dato, in un registro diversamente inizializzato a zero. Ok, in un sorgente ben scritto le tre espressioni complesse vengono suddivise in operazioni elencate ordinatamente, oppure raggruppate in funzioni diverse, però se questo ipotetico compilatore fosse fatto bene potrebbe riconoscere da solo le istruzioni che compongono una certa espressione, o magari valutare se le tre funzioni possono essere eseguite separatamente, o se invece modificano dati che servono alle altre (ad esempio una variabile globale) e si deve rispettare un certo ordine (addirittura questo potrebbe facilitare il debug). Estendendo questo modo di lavorare si potrebbe ottenere forse una parallelizzazione più capillare di quella che si può creare oggi, e magari ritrovarsi con qualche thread in più laddove al programmatore sia sfuggita la possibilità di suddividere ulteriormente un certo processo. Chiaramente servirebbe tantissimo lavoro nella progettazione di un compilatore simile, e una eccessiva ricerca di parallelismo potrebbe incappare in qualche collo di bottiglia, però sarebbe comodo.

Poi ho divagato su qualche sistema distribuito più o meno futuristico, perchè è lì che si ha nel software il maggior freno allo sviluppo. In particolare, per quanto riguarda la domotica l'elettronica di base per l'automatizzazione degli elettrodomestici esiste da una decina d'anni, il problema principale sta nel software di gestione, anche se il vero nodo da sciogliere sono i linguaggi di interazione con l'uomo, non si può pretendere che la zia Giuseppa o la signora Marisa imparino complicate sequenze di codici numerici (l'ideale sarebbe un bel sistema a riconoscimento vocale, in grado di interpretare il più possibile il linguaggio naturale, se poi capisse anche qualche dialetto sarebbe perfetto )

Ciao

[cdimauro]

Francamente sono un po' scettico su un approccio simile: un compilatore, IMHO, dovrebbe essere "istruito" dal programmatore per fargli riconoscere le parti che può parallelizzare, e non farlo da solo. Anche perché i vantaggi non derivano dal prendere un'espressione e suddividerla in tanti pezzi da mandare in esecuzione, per poi combinare i risultati: ciò implicherebbe una strettissima e velocissima interazione fra i processori. Meglio, invece, suddividere in maniera netta (e indipende) il lavoro da svolgere, e assegnarlo a ogni processore. Ad esempio, se ho un'immagine 320x240 da renderizzare, ne assegno 1/4 a ognuno di un sistema (a 4 vie o cluster), per poi attenderne il completamento.
Tutto ciò comporta una complessità decisamente ridotta del compilatore, e un controllo migliore sul risultato.
Questo, è la mia opinione, chiaramente...

[xeal]

Originariamente inviato da cdimauro
Francamente sono un po' scettico su un approccio simile

Se parliamo di quello che si può fare/serve oggi, lo sono anch'io, a meno che (e forse si dovrebbe fare, ma oggi sarebbe una complicazione forse eccessiva) non si progetti un compilatore che ottimizzi per processori diversi tenendo conto, ad esempio, del numero di alu o della cache e del preload che si va a fare. Comunque, parlavo di spunti di riflessione / elementi di sperimentazione nell'ottica di una implementazione (per fini non sperimentali) futura (che ovviamente tanto futura non sarebbe se si trovasse una qualche utilità a breve termine).

Anche perché i vantaggi non derivano dal prendere un'espressione e suddividerla in tanti pezzi da mandare in esecuzione, per poi combinare i risultati: ciò implicherebbe una strettissima e velocissima interazione fra i processori.

Infatti, pensavo proprio ad uno scenario del genere come campo di applicabilità di questo approccio, magari un sistema a più vie con processori multicore progettati ad hoc, con cache condivisa e link interno di comunicazione alla stessa frequenza dei core, cosa che nei prossimi anni potrebbe diventare lo standard produttivo, visto l'andazzo (almeno in apparenza). In questo caso potrebbe avere senso indirizzare dei macroblocchi di lavoro (i 4 quarti di immagine da renderizzare) a ciascun processore, ognuno dei quali eseguirà in parallelo il proprio carico di lavoro grazie alla stretta e veloce interazione tra i core. In un certo senso, sarebbe come estendere al calcolo distribuito il lavoro di riordino delle istruzioni che si fa per cercare di migliorare l'esecuzione out of order, solo che non si tratterebbe di una pre-ottimizzazione, completata dalla logica della cpu, ma di un affinamento del lavoro di progettazione, per cercare di sfruttare al meglio, ove possibile, le caratteristiche del sistema di cui si dispone. Chiaramente non si può eccedere nella suddivisione, perchè si rischierebbe di peggiorare le prestazioni, non credo che avrebbe molto senso far eseguire una sola somma ad ogni core, con tutte le altre alu in "pausa pranzo".

Poi, in futuro (un futuro che potremmo anche non vedere, toccando...ci siamo capiti ) i computer come li conosciamo oggi potrebbero essere sostituiti da sistemi quantistici, e in tal caso la ricerca "estrema" del parallelismo potrebbe essere l'unico modo per non sprecare risorse di calcolo enormi.

Tutto ciò comporta una complessità decisamente ridotta del compilatore

Viceversa, quello che dico io comporta un lavoraccio , però, non mi sembra assurdo pensare che tra non molto tempo useremo (o potremmo usare) compilatori basati sulle tecniche più avanzate di IA, integrati in ambienti di sviluppo visuale (con accoppiate tipo rational rose + visual studio o builder della borland, et similia) molto sofisticati, in grado di analizzare le specifiche e i sorgenti che hai prodotto e "suggerirti" un modello di struttura dei processi alternativo, oppure confrontarne diversi preliminarmente per valutare quale possa rispondere meglio a determinate specifiche prima di passare alla stesura del codice, o di parti specifiche di esso. E' questo il tipo di automatismi a cui mi riferivo, non certo lasciar fare tutto a un "programmino": sarebbe troppo comodo (per chi ci paga/pagherà lo stipendio) e attualmente per certi versi impensabile (fortunatamente? ).

Questo, è la mia opinione, chiaramente...

Se poso la sfera di cristallo e torno con i piedi per terra, diventa anche la mia...

Ciao

[cdimauro]

Originariamente inviato da xeal
Se parliamo di quello che si può fare/serve oggi, lo sono anch'io, a meno che (e forse si dovrebbe fare, ma oggi sarebbe una complicazione forse eccessiva) non si progetti un compilatore che ottimizzi per processori diversi tenendo conto, ad esempio, del numero di alu o della cache e del preload che si va a fare.

Considera che già adesso i compilatori, sebbene facciano un buon lavoro, non ottimizzano il codice al massimo delle possibilità per un processore. Se estendiamo il discorso a più processori, la situazione può soltanto peggiorare, IMHO.

[...]In questo caso potrebbe avere senso indirizzare dei macroblocchi di lavoro (i 4 quarti di immagine da renderizzare) a ciascun processore, ognuno dei quali eseguirà in parallelo il proprio carico di lavoro grazie alla stretta e veloce interazione tra i core. In un certo senso, sarebbe come estendere al calcolo distribuito il lavoro di riordino delle istruzioni che si fa per cercare di migliorare l'esecuzione out of order, solo che non si tratterebbe di una pre-ottimizzazione, completata dalla logica della cpu, ma di un affinamento del lavoro di progettazione, per cercare di sfruttare al meglio, ove possibile, le caratteristiche del sistema di cui si dispone.

Già questo ricalca, appunto, il concetto di calcolo distribuito. Ma a questo punto tanto vale rimanere legati al classico, piuttosto che pensare di applicarlo anche per il riordino delle istruzioni o l'allocazione dinamica delle risorse. Infatti, se ci pensi bene, già la circuiteria di OOO degli attuali processori è una delle parti più complesse e critiche di una CPU: un procedimento simile per la distribuzione del carico di lavoro in hardware non oso immaginare cosa potrebbe comportare...

Chiaramente non si può eccedere nella suddivisione, perchè si rischierebbe di peggiorare le prestazioni, non credo che avrebbe molto senso far eseguire una sola somma ad ogni core, con tutte le altre alu in "pausa pranzo".

Appunto. E se è già difficile riuscire a coordinare dei sistemi distribuiti per spremerli al massimo, figurati se si pensa di fare lo stesso a livello di core dei processori.

Poi, in futuro (un futuro che potremmo anche non vedere, toccando...ci siamo capiti )

Io mi sto toccando...

i computer come li conosciamo oggi potrebbero essere sostituiti da sistemi quantistici, e in tal caso la ricerca "estrema" del parallelismo potrebbe essere l'unico modo per non sprecare risorse di calcolo enormi.

Per adesso sono un po' scettico sulle reali capacità di un possibile computer quantistico: mi suona paradossale lo sfruttamento deterministico del lavoro prodotto da macchine non deterministiche.

Viceversa, quello che dico io comporta un lavoraccio , però, non mi sembra assurdo pensare che tra non molto tempo useremo (o potremmo usare) compilatori basati sulle tecniche più avanzate di IA, integrati in ambienti di sviluppo visuale (con accoppiate tipo rational rose + visual studio o builder della borland, et similia) molto sofisticati, in grado di analizzare le specifiche e i sorgenti che hai prodotto e "suggerirti" un modello di struttura dei processi alternativo, oppure confrontarne diversi preliminarmente per valutare quale possa rispondere meglio a determinate specifiche prima di passare alla stesura del codice, o di parti specifiche di esso. E' questo il tipo di automatismi a cui mi riferivo, non certo lasciar fare tutto a un "programmino": sarebbe troppo comodo (per chi ci paga/pagherà lo stipendio) e attualmente per certi versi impensabile (fortunatamente? ).

Guarda, come ho detto, è già difficile pensare di avere un compilatore che ottimizza il codice per un processore (oggettivamente è impossibile che possa esistere), figuriamoci mettergli un po' di intelligenza in più.
"Non c'è intelligenza senza conoscenza" è un motto coniato da uno dei più grandi esperti di IA (non ricordo il nome in questo momento), e che racchiude in sé i problemi intriseci della simulazione di un comportamento intelligente da parte di sistemi calcolatori.

Se poso la sfera di cristallo e torno con i piedi per terra, diventa anche la mia...

Ciao

Ciao