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

Il passaggio al processo produttivo a 0.09 micron, da poco concluso per Intel e in via di attuazione per AMD, nasconde molti problemi mai sperimentati in precedenza

Click sul link per visualizzare la notizia.

sono d'accordo con Paolo, AMD potrebbe avere meno problemi perchè il suo K8 ha un IPC più alto di Intel, ma i 2.5 ghz del G5 sono molto vicini alle frequenze attuali degli Athlon 64 e FX... bisogna vedere se la struttura interna del microprocessore consente migliori tolleranze...

Certo il fatto che però dicano di essere nei tempi e insistano che nulla cambierà nella roadmap mi fa ben sperare. Magari le cose dati i loro ritmi ridotti di crescita di frequenza possono andare bene. Lo scopriremo quando qualcuno tenterà di overcloccare i primi sample a 0.09 (si sà capitano sempre nelle manone luride di qualche smanettone :D )

Spero che rulli nel mercato il Winchester con 0.09 micron, così quelli a 0.13 costeranno meno 8)

certo che se si ostinano a risparmiare qualche mm2 senza dare "aria" ai transistor non vedo come possano ottenere risultati decenti..
analiticamente i watt che sprigionano queste CPU sono sempre piu' alti, anche se il processo diminuisce (leakage della corrente non consente di abbassare il voltaggio), ma la loro superficie di scambio diminuisce sempre di piu'; logica vuole che se si e' raggiunto un certo limite di dissipazione l'unica cosa sarebbe di aumentare la superficie di scambio: dissipatori, sistemi piu' performanti tipo quello apple, ma anche suerfice utile di interscambio, ossia la grandezza del die.
Speravo che con il 775 le cose si aggiustassero, ma ancora la vedo buia per intel..
con il 775 era probabile che intel avesse messo piu' punti di alimentazione perche' le distaze (in rappporto all'alimentazione) tra' i vari transistors erano superiori, ma i prescott credo che abbiano la stessa alimentazione sia con il vecchio socket che con il nuovo, percio' questo vantaggio sembra svanito, percio' il problema non era troppa corrente in pochi punti, ma troppe interferenze che costringono ad aumentare il voltaggio..
forse e' anche dovuto all'uso di wafer da 12"? o si usano ancora gli 8" per queste CPU? forse bisognerebbe scendere anche con la dimensione dei wafer, per riuscire ad avere piu' precisione?
se s'incontrano tutti qquesti problem a 0.09, a 0.065 non oso pensare quanto tempo ci vorra'...

A questo punto AMD ha una grossa occasione da giocarsi...vedremo come andrà......

per quanto riguarda l'aumento delle quantità delle cache è sempre complicato capire se e quanto questo migliori le prestazioni del processore.

Quando si parla di AMD non si parla mai dell'architettura SOI. E' curioso anche perchè in passato se ne parlava come se doveva essere il vero toccasana per l'innalzamento delle frequenze di clock. Adesso invece a me sembra un buco nell'acqua : le frequenze dei processori AMD sono sempre alquanto bassine (rispetto ad Intel) e non sembra ci siano essere dei vantaggi neanche col processo a 0,09 micron.

il silenzio di amd per certi versi può essere preokkupante, come potrebbe essere un segno positivo...

anche se io penso che se le cose non vanno bene non stanno certo li a dircelo, rovinerebbero il loro periodo positivo agli occhi del mercato. Poi anche se sono nelle loro stime iniziali, alla amd ci stanno mettendo molto + tempo per sviluppare questa tecnologia.

Vedremo!

Originariamente inviato da Fabio_si
Quando si parla di AMD non si parla mai dell'architettura SOI. E' curioso anche perchè in passato se ne parlava come se doveva essere il vero toccasana per l'innalzamento delle frequenze di clock. Adesso invece a me sembra un buco nell'acqua : le frequenze dei processori AMD sono sempre alquanto bassine (rispetto ad Intel) e non sembra ci siano essere dei vantaggi neanche col processo a 0,09 micron.

Anche sul lato intel non è che vada meglio ... la tanto decantata "Strained Silicon" non mi sembra stia aiutando molto ... :nono:

Sarei proprio curioso di vedere se l'introduzione dei Low-K (come nelle nuove schede ATI) porterà miglioramenti più tangibili ... :muro:

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..

Vabbè, anche se le frequenze sonno "bassine", comunque il processore più prestante che è per ora disponibile è l'athlon 64 3800+ (939). In fin dei conti nn c'è scritto da nessuna parte che per migliorare le prestazioni si debba solo aumentare le frequenze di clock. Questo è quello che ci ha inculcato in testa Intel da sempre....

è vero che prestazioni non significa mhz e comunque anche Intel non punta più su questo paradigma, infatti ha introdotto pure lei il MN

Inviato da: lucusta
certo che se si ostinano a risparmiare qualche mm2 senza dare "aria" ai transistor non vedo come possano ottenere risultati decenti..
analiticamente i watt che sprigionano queste CPU sono sempre piu' alti, anche se il processo diminuisce (leakage della corrente non consente di abbassare il voltaggio), ma la loro superficie di scambio diminuisce sempre di piu'; logica vuole che se si e' raggiunto un certo limite di dissipazione l'unica cosa sarebbe di aumentare la superficie di scambio: dissipatori, sistemi piu' performanti tipo quello apple, ma anche suerfice utile di interscambio, ossia la grandezza del die.
Speravo che con il 775 le cose si aggiustassero, ma ancora la vedo buia per intel..
con il 775 era probabile che intel avesse messo piu' punti di alimentazione perche' le distaze (in rappporto all'alimentazione) tra' i vari transistors erano superiori, ma i prescott credo che abbiano la stessa alimentazione sia con il vecchio socket che con il nuovo, percio' questo vantaggio sembra svanito, percio' il problema non era troppa corrente in pochi punti, ma troppe interferenze che costringono ad aumentare il voltaggio..


In effetti anch'io non riesco a capire come mai non aumentino leggermente l'area del die in modo da ottenere una maggior superfice di dissipazione!
Comunque l'incremento dei pin anzi...dei contatti (visto che in pin non ci sono più) pare che sia dovuto essenzialmente all'introduzione della parte di architettura preposta all'elaborazione a 64bit.

Inviato da: lucusta
forse e' anche dovuto all'uso di wafer da 12"? o si usano ancora gli 8" per queste CPU? forse bisognerebbe scendere anche con la dimensione dei wafer, per riuscire ad avere piu' precisione?

Tutti i Prescott sono prodotti in wafer da 300mm e ovviamente con il processo di produzione a 90nm.
La dimensione del wafer purtroppo non conta nulla, e poi con le componenti ottiche utilizzate oggi riescono ad avere una precisione elevatissima in ogni parte del wafer, poi tutt al più i core meno "prestanti" sarebbero sempre quelli più esterni che infatti sono quelli che vanno a frequenze inferiori, la parte centrale di un wafer da 300mm ha la stessa qualità di un wafer da 200mm (salvo casi di wafer sfigati o di impurità che possono far insorgere problemi...ma questo è un altro discorso).

Inviato da: lucusta
se s'incontrano tutti qquesti problem a 0.09, a 0.065 non oso pensare quanto tempo ci vorra'...

Davvero...forse per allora sarò nonno:D credo anche io che ci vorrà un bel pò!!

Inviato da: atomo37
per quanto riguarda l'aumento delle quantità delle cache è sempre complicato capire se e quanto questo migliori le prestazioni del processore.

Non è necessariamente vero, in teoria (giusto per fare un esempio... anche se un pò grossolano) basta sapere con che regole viene gestita la cache dai vari processori, anche sapere solamente se un processore utilizza la cache in modo esclusivo o inclusivo può aiutare a cabire se un processore beneficerà o meno di un eventuale aumento di cache.

Inviato da: Fabio_si
Quando si parla di AMD non si parla mai dell'architettura SOI. E' curioso anche perchè in passato se ne parlava come se doveva essere il vero toccasana per l'innalzamento delle frequenze di clock. Adesso invece a me sembra un buco nell'acqua : le frequenze dei processori AMD sono sempre alquanto bassine (rispetto ad Intel) e non sembra ci siano essere dei vantaggi neanche col processo a 0,09 micron.

La tecnica SOI non è stata affatto un buco nell'acqua, ne per IBM ne tanto meno per AMD, certo, all'inizio era un pò un problema per quest'ultima riuscire ad ottenere dei buoni wafer e delle rese produttive accettabili, ma adesso tutto quadra a dovere, e il SOI stà facendo il suo dovere, poi è ovvio che come tutte le cose dovrà continuamente essere aggiornato, ma prova un attimo a pensare se adesso i processri di AMD non facessero uso di tale tecnica, che consumi avrebbero?? e che frequenza raggiungerebbero?!?!
Ti ricordo che il SOI in teoria può abbattere i consumi e aumentere le frequente di un valore compreso tra il 15% (situazione peggiore) e il 30% (situazione ideale), prova un pò a sommare e a sottrarre questi valori alle caratteristiche dei vari processori oggi nel listino di AMD, poi fammi sapere se questò SOI è un buco nell'acqua!! ;)

ma se i 0,09 micron danno questi problemi, perche non hanno diciamo progettato per i 0,10/11 micron? (leggermente piu grande), vendendo dai 0,13 micron sarebbe stato comunque un vantaggio... magari nn c'erano sti problemi termici e di consumi..

Ma gli svantaggi dell'aumento di cache? Mi pare che Paolo abbia toccato solo uno dei due (e sottointentendone molti) punti annunciati nelle prime riche dell'articolo...

Guarda che la dimensiione viene diminuita proprio per abbattere i problemi relativi alla temperatura di esercizio, di consumo e, non da ultimo, prestazionali.

Passando a un 0.10 anzichè allo 0.09 si sarebbero gli stessi problemi riscontrati oggi, ma in misura maggiore. :)

p4 nw 3ghz - 0,13 micron
p4 prescott 3ghz - 0,9 micron

hanno uguali frequenze, ora secondo cio che mi hai detto scendendo a 0,9 micron ci sarebbero dovuti essere risparmi energetici e di calore,,, a me invece pare che abbiano risparmiato quei 2 milligrammi di silicio cosi da avere piu' dollari nel portafoglio...

dicevo sostanzialmente che seppure devono salire di frequenza rendendo il core piu' piccolo, magari se fossero passati dai 0,13 micron a 0,11 , sapendoli gestire meglio a quest'ora non avevamo i problemi del 0,9 micron... certo che pero avrebbero risparmiato meno soldi :rolleyes: e non sarebbero riusciti a progettare cpu future da oltre i 3,6 ghz

dimmi se sbaglio ragionamento...
-----------------------

penso che se avessero aumentato la cache l2 l3, i processori ci costerebbero di norma quanto i p4 extreme edition... allora si ci sarebbero incrementi prestazionali, pero risulta TROPPO costoso per l'utente medio/value

Il problema è che passando dal P4 Northwood al P4 Prescott, oltre ai problemi produttivi, è aumentato anche parecchio il numero di transistor (stadi della pipeline+cache+ estensioni nascoste a 64 bit), e quindi di conseguenza i consumi, anche se la superficie del die è più piccola. Se Intel avesse fatto un semplice die shrink come farà AMD per l'A64 (almeno per le prime revisioni del core a 0.09) avrebbe di sicuro avuto molti meno problemi.

AMd è solito imparare dagli errori suoi e degli altri, sul k8 ci hanno lavorato dai tempi del thunderbird e sul k9 già ne stavano parlando prima dell'uscita del k9. Amd già sta pensando allo 0,065.


La cpu + potente attualmente è il 3800+. Intel cosa ha? un 3,6 a mala pena. Intel farà uscire i prescott 2 fino a 3,7 e intanto Amd ha ancora tempo per lavorare sullo 0,09.

AMd prevede anche il dual core a 0,09 e ancora non ha ami fatto una dichiarazione ufficali sui problemi dello 0,09.

Il fatto è che Intel per risparmiare un po' di silicio ha adottato in maniera prematura lo 0,09 , quando il Prescott ripetto al Northwood non offre nessun vantaggio per l'acquirente.

Amd prima di proporre lo 0,09 ci metterà parecchio tempo, memore dei problemi del toro A e anche perchè se Intel non presenta una cpu + potente della sua e ha difficoltà con le rese del prescott non ha senso presentare subito un nuovo core + performante a 0,09.
Molto probabilmente con lo 0,13 farà uscire pure il 4000+ (2,6 con 512k) e 4200+ (2,6 con 1mega) facendo usciore un nuovo step tipo il cg.



leggetevi questo, preso da 3ditalia.

I futuri modelli di Athlon 64!
News di pier - ore 0:25
AMD proporrà un nuovo processore di fascia alta per la fine dell'anno: l'Athlon 64 FX-55. Con frequenza a 2.6 GHz questo processore, previsto per il quarto trimestre 2004, sarà ancora costruito con processo a 0.13 micron.
Dopo l'Athlon 64 FX-55, AMD proporrà l'Athlon 64 FX-57 a 0.09 micron e basato sul core "Winchester". Oltre questo, AMD metterà in commercio anche nuovi modelli di Athlon 64 classici con 512 KB di memoria cache.
L'Athlon 4000+ classico è atteso per il quarto trimestre 2004, il 4200+ per il primo trimestre 2005 ed il 4400+ per iol secondo trimestre 2005. Tutti questi nuovi processori adotteranno il Socket 939.

AMD ha il vantaggio di usare il SOI piuttosto che il fallimentare strained silicon di intel, però d'altro canto intel ha risorse economiche maggiori e non impiegherà molto a trovare una soluzione ai 130W massimi del prescott a 0.09

C'è da contare che i passaggi di produzione da 0.15 a 0.13 han creato tanti problemi, perchè 0.13um è la lunghezza d'onda degli ultravioletti che ernao di norma usati per incidere. Così tutti son dovuti passare ai raggi X, con evidenti problemi delle nuove tecnologie.

Tempo fa ci fu un articolo che parlava della produzione di vafer di silicio in acqua, per accorciare lunghezza d'onda della luce che scolpisce le piste e produrre schemi molto più precisi. Però nessuno ancora si è buttato su questa tecnologia.

Mi viene il dubbio che uno dei problemi sia il modo in cui i processori sono raffreddati ancora oggi.
In pratica un P4 delle versioni più recenti ha la stessa geometria di un 386SX con una sola superficie radiante in alto e un bel sandwich di silicio sotto (che non è il massimo per disperdere calore).

se solo si riuscisse ad utilizzare anche la superficie inferiore per irradiare calore in modo efficiente si salirebbe parecchio con le frequenze senza problemi.

Magari si finirà come con gli ultimi CRAY, ad immergere l'intero processore dentro un liquido inerte ad elevata conduzione termica (e a raffreddare con un radiatore esterno.

LvP

Inviato da: Lud von Pipper
Mi viene il dubbio che uno dei problemi sia il modo in cui i processori sono raffreddati ancora oggi.
In pratica un P4 delle versioni più recenti ha la stessa geometria di un 386SX con una sola superficie radiante in alto e un bel sandwich di silicio sotto (che non è il massimo per disperdere calore).

se solo si riuscisse ad utilizzare anche la superficie inferiore per irradiare calore in modo efficiente si salirebbe parecchio con le frequenze senza problemi.


Stò facendo anche io lo stesso ragionamento da molto tempo, non riesco infatti a capire come mai non abbiano pensato al mondo di poter raffreddare il processore su almeno due fronti, Sarebbe una cosa che consentirebbe di smaltire molto più efficacemente il calore e, perchè no, di salire un pò in frequenza!!
Mhà:confused:

Inviato da: Lud von Pipper
Magari si finirà come con gli ultimi CRAY, ad immergere l'intero processore dentro un liquido inerte ad elevata conduzione termica (e a raffreddare con un radiatore esterno.


I processori utilizzati all'interno dei Computer Cray non sono esattamente immersi in un liquido inerte, bensi questi hanno sopra di loro una sorta di ugello che gli spruzza sopra questo liquido che evapora molto velocemente in quanto assorbe con rapidità il calore; il gas prodotto dall'evaporazione di questo liquido viene poi aspirato in appositi "macchinari" che ne smaltiscono il calore!

Inviato da: Dreadnought
AMD ha il vantaggio di usare il SOI piuttosto che il fallimentare strained silicon di intel, però d'altro canto intel ha risorse economiche maggiori e non impiegherà molto a trovare una soluzione ai 130W massimi del prescott a 0.09

Io per lo meno per adesso aspetterei a giudicare così negativamente lo Streined Silicon, la tecnica in se stessa è molto valida, tanto quanto lo è quella SOI, molto probabilmente però com'è stato per quest'ultima, richiede di essere rodata ed affinata.
Il fatto che sia molto valida te lo dimostra il fatto che compagnie come IBM, AMD, la stessa Intel mi pare, stiano lavorando alla possibilità di implementere entrambe le tecnologie per la produzione dei wafer, mi pare che si chiami Streined Silicon Directly On Insulator (S.S.D.I.O.) o qualcosa del genere!

Il problema del consumo del Prescott penso che sia da imputare all'innalzamento del numero dei transistor effettuato con l'introduzione del processo di produzione a 90nm, sono convinto infatti che se avessero effettuato solamente un die shrink non sarebbero incorsi in tutti quei problemi.

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...

Inviato da: Dreadnought
C'è da contare che i passaggi di produzione da 0.15 a 0.13 han creato tanti problemi, perchè 0.13um è la lunghezza d'onda degli ultravioletti che ernao di norma usati per incidere. Così tutti son dovuti passare ai raggi X, con evidenti problemi delle nuove tecnologie.


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!

Inviato da: Dreadnought
Tempo fa ci fu un articolo che parlava della produzione di vafer di silicio in acqua, per accorciare lunghezza d'onda della luce che scolpisce le piste e produrre schemi molto più precisi. Però nessuno ancora si è buttato su questa tecnologia.

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

bye bye! :)

Originariamente inviato da ShadowX84
mi pare che si chiami Streined Silicon Directly On Insulator (S.S.D.I.O.) o qualcosa del genere!

Si, è quella, hai solo invertito la I e la O nell'abbreviazione :p


ma quali potrebbero essere questi buoni motivi???Mha...

Principalmente marketing, per sfruttare fino all'osso il trend dei MHz, l'immagine data dall'esserre stati i primi a introdurre la nuova tecnologia e la possibilità/speranza (dati i problemi iniziali con le rese e il thermal throttling) di risparmiare nella produzione dei core. Lo dimostra l'ottima architettura dei sistemi centrino e i non-problemi (se non mi sono perso qualcosa) nella produzione dei dotan a 90 nm.

Per il resto, credo che una maggiore precisione nella stampa dei circuiti potrebbe aiutare, migliorando le rese soprattutto, ma anche la qualità (non vorrei essere fuori strada, ma i chip dovrebbero risentire meno delle imperfezioni nel silicio e dovrebbero esserci meno fenomeni parassiti, correggimi se sbaglio).

Ciao.

Sembra che AMD non avrà gli stessi problemi di Intel
Ripeto...sembra
http://amdpower.altervista.org/index.php?action=fullnews&showcomments=1&id=271

Infatti non credo che i problemi del prescott derivino dal passaggio a 90nm, piuttosto dal fatto che il pentium e' ormai al capolinea e non ha piu' dove andare.
Se si considerano i 5ghz come tetto massimo ed il fatto che i 64bit sono ancora all'inizio della loro carriera, l'amd64 ha tantissimo da offrire!!!
Se si pensa inoltre che Intel non e' in grado di offrire un processore in grado di battere l'ultima proposta amd, la dice lunga sugli immensi problemi che Intel sta affrontando!!!
Io non sono fan di Intel ma non avrei mai creduto e/o pensato che si sarebbero ritrovati in una situazione del genere: Intel-Amd=4-5, con Intel senza nessuna riserva ne speranza di battere amd. E stiamo ancora parlando di tecnologia 32bit!!!
E chi glielo dice a Bill$ che fra non molto tutti i personal avranno amd64 e knoppix!?!?!?!

notizia fresca di giornata, penso che adesso Intel e tutti gli intelisti cercheranno di smentire per giustificare il prescott.

L'intel ha problemi con il Prescott ma non con il dothan che a quanto pare le diffcioltà di gioventù le ah supperate prima di essere immesso sul mercato.



AMD: tutto ok per la migrazione verso i 90 nm
News di pier - ore 7:57
La migrazione verso la tecnologia a 90 nm, non è stata indolore, come conferma l'esperienza di IBM e di Intel. Quest'ultima sembra ad avere difficoltà a produrre Pentium 4 Prescott a 3.4 e 3.6 GHz. Il Pentium 4E 3.4 GHz è già disponibile nei negozi on line, ma in quantità assai limitate.
AMD conta di lanciare il suo Athlon 64 @ 90 nm prima della fine dell'anno e per bocca di Damon Muzny afferma di non incontrare alcuna difficoltà (dichiarazione fatta ai colleghi di AMDZone), sia in termini di consumo elettrico che di dissipazione.

preciso che questa è la prima dichiarazione proveniente da AMd sui problemi dello 0,09 , fino adesso si è speculato su notizie che non erano mai state confermate.

L'estensore dell'articolo dimentica un fatto fondamentale: quello che viene indicata come dimensione del processo produttivo (0,13 micron ad es.) si riferisce al passo di gate del transistor. Ora piu' questo passo viene ridotto piu' ci si allontana dal consolidato modello matematico su cui ci si basa per studiare/predire il comportamento dei MOSFET.
E questa e' una delle difficolta' piu' grandi a cui vanno incontro i progettisti di AMD e Intel quando le due aziende decidono di ridurre il processo produttivo dei transistor stessi (portandolo come in questo caso a 0,09 micron).

Originariamente inviato da Mikel76
L'estensore dell'articolo dimentica un fatto fondamentale: quello che viene indicata come dimensione del processo produttivo (0,13 micron ad es.) si riferisce al passo di gate del transistor. Ora piu' questo passo viene ridotto piu' ci si allontana dal consolidato modello matematico su cui ci si basa per studiare/predire il comportamento dei MOSFET.
E questa e' una delle difficolta' piu' grandi a cui vanno incontro i progettisti di AMD e Intel quando le due aziende decidono di ridurre il processo produttivo dei transistor stessi (portandolo come in questo caso a 0,09 micron).

ti ripeto la notiziuola presa da 3ditalia:

AMD: tutto ok per la migrazione verso i 90 nm
News di pier - ore 7:57
La migrazione verso la tecnologia a 90 nm, non è stata indolore, come conferma l'esperienza di IBM e di Intel. Quest'ultima sembra ad avere difficoltà a produrre Pentium 4 Prescott a 3.4 e 3.6 GHz. Il Pentium 4E 3.4 GHz è già disponibile nei negozi on line, ma in quantità assai limitate.
AMD conta di lanciare il suo Athlon 64 @ 90 nm prima della fine dell'anno e per bocca di Damon Muzny afferma di non incontrare alcuna difficoltà (dichiarazione fatta ai colleghi di AMDZone), sia in termini di consumo elettrico che di dissipazione.

bhe'.. c'e' da dire che e' arrivata anche un anno dopo.. non sono certo pro intel, e sicuramente AMD non ha avuto necessita' di cambiare tecnologia per via della concorrenza, ma cio' non s'ignifica che sia meglio o peggio d'intel, significa che e' stata piu' oculata, potendo mettere appunto la tecnologia senza farla scontare sul cliente; con la bassa quota di mercato che ha AMD, un rifiuto del mercato stesso sarebbe una gran bella mazzata; intel si puo' permettere di fare due o tre processori bacati.. purtroppo.

x ShadowX84:
non e' facilmente realizzabile la soluzione di raffreddare il die sia sopra che sotto, in quanto ci sono i contatti elettrici, e poi non avresti la possibilita' di fissarlo al pcb del processore.. sarebbe troppo delicato, e il leyout delle schede madri diverrebbe impossibile (si dovrebbe ritornare come minimo su cartridge).

Bisognerebbe sapere anche che tippo di transistor usano i progettisti di intel/amd. Non esistono solo i mosfet: senza arrivare alle famiglie che usano materiali diversi rispetto ai cmos, che hanno campi di impiego decisamente di nicchia (per quanto ne so), da un po' di tempo si studiano tecnologie ibride mosfet - j_qualcosa (non ricordo esattamente), per coniugare ai vantaggi dei mosfet quelli di questa vecchia famiglia (forse bipolari?). Comunque le affermazioni di Muzny credo che si basino sui risultati dei test di produzione più che sui calcoli matamatici, che a quei livelli sono comunque molto complessi (credo che la linearizzazione la tirino fuori solo quando da risultati certi, per intervalli di valori decisamente ristretti).

Sapremo qualcosa di più preciso quando qualcuno avrà un bel sample tra le mani da mettere sotto torchio e spremere fino all'osso... perdon, al core :D

Inviato da: lucusta
x ShadowX84:
non e' facilmente realizzabile la soluzione di raffreddare il die sia sopra che sotto, in quanto ci sono i contatti elettrici, e poi non avresti la possibilita' di fissarlo al pcb del processore.. sarebbe troppo delicato, e il leyout delle schede madri diverrebbe impossibile (si dovrebbe ritornare come minimo su cartridge).

Lo so lo so, io sinceramente l'unica soluzione che riesco ad immaginare è un'idea simile a quella utilizzata da Apple per i suoi computer, cioè quella di utilizzare una mini schedina sulla quale si trovano i processori, il tutto collegato poi alla scheda madre.

Fatto questo poi si dovrebbe procedere a trovare una soluzione che consenta di raffreddare da ambo le parti i procesori, ma li insorgerebbero i problemi relativi alla collocazione dei pin che non consentirebbe di adattare un dissipatore nella parte inferiore della CPU, e siccome dubito che si possano spostare i pin sui lati del processore (visto anche il numero sempre crescente di pin), bhè...sono di nuovo punto e a capo...!
Ok ok...io ho detto la mia :)..tu che suggerisci??

Bye ;)

C'è anche da dire che Intel c'è arrivata ben prima, ma i problemi coi Prescott non li ha ancora risolti...

ShadowX84
costruire CPU con logiche piu' performanti, e che consumino meno..
(stessa risposta per cdimauro).

lo svantaggio dei PC in raffronto agli Apple e' proprio la standardizzazione..
Apple dalla sua ha la possibilita' di costruire interi computer, dal case alla scheda madre, alla CPU, mentre un PC e' senza un vero e proprio standard..
Le CPU montate sull'ultimo G5 non sarebbero nemmeno pensabili in un PC normale (in pratica hanno fatto una dream-machines, una macchina che su base PC si realizza in pezzi quasi unici),
ed e' questa la "forzata" limitazione delle CPU AMD e Intel; oltre al fatto che comunque stiamo pagando gli investimenti, sbagliati, di concezioni architetturali troppo ose'.
Intel ci ha fatto digerire il willamate con il primo netbrust, immaturo e lento, poi ci ha dato il northwood, un netbrust quasi degno di essere usato, ma la poca lungimiranza ci ha potrato al prescott, una CPU che sta' scontando la poca efficenza a scapito di un'aumento di mhz e di temperature che e' ancora per poco sostenibile.
Una soluzione migliore ce l'ha concessa AMD, ma anche questa dovra' comunque allungare le pipeline se vuole salire con i mhz.
Ora le cose si staranno aggiustando con cpu dual core, ma, con due core della stessa inefficente architettura.
Fra' qualche anno o raddoppiano nuovamente i core, o saremo allo stesso punto; anche perche' gli step sul silicio sono ridotti all'osso:
0.09>0.065>0.045>0.032>0.022
e poi il silicio non avra' piu' ragione di essere il supporto prediletto per le microcircuitazioni.
tra' 10 anni saremo senza ulteriori giovamenti dalla riduzione del gate, e se continua cosi', senza possibilita' di aumentare ancora la frequenza..
a 0.022 si potra' sperare a transistor che clockano a 10ghz (come ha dimostrato intel, ma con un solo transistor, me ne mettessero 100 che fanno il lavoro di 100), ma con che architettura?, un'architettura che avra' si e no l'efficenza di un P4 a 7.5ghz, ben poca cosa tra' 10 anni (considerando la curva del progresso).
E allora, se non si puo' sperare in aumenti di clock proporzionali alle prestazioni, se le architetture non si possono sviluppare decentemente, perche' non ripensare gia' ora all'intera architettura complessiva dei PC?
Non m'interessano piu' di tanto le CPU a 2 core nel die, preferirei una CPU con un solo core nel die, ma una struttura modulare capace di essere espansa all'infinito, mattoncino su mattoncino, capace di essere flessibile per ogni tipo di utilizzo, adeguando la potenza.
Oggi il core di un P2 a 1ghz basta per far girare applicativi modesti come la navigazione in rete(supportato da una buona banda sulle memorie), 2 basterebbero per un word rocessor, 4 per il giochino stupido, 8 come macchina professionale, e cosi' via..
un core P2 a 0.09 a 1 ghz consumerebbe meno di 10 watt, con 80 watt si avrebbe un'efficenza simile ad un P4 a 5 ghz..

In poche parole, sfruttiamo quello che gia' conosciamo in modi diversi, senza ostinarci nel perseguire strade troppo tortuose.

per chiarire il concetto: avete mai giocato coni lego?

Originariamente inviato da lucusta
per chiarire il concetto: avete mai giocato coni lego?


L'errore di Intel è stato allungare ulteriormente le pipeline.

Se faceva il northwood a 1mega di cache o il galatin a 0,09 a quest'ora erano dolori per AMd.
Intel è ancora legata allo sterotipo + lungo è meglio. Il northwood era il massimo e poteva essere migliorato ancora con aumento di bus e cache ma intle ha preferito strafare allungato le pipe e adottando un processo costruttivo non collaudato.

I prescott sono ancora cpu sperimentali egli utenti dei beta tester che pagano per testarle.

Ati docet: il processo costruttivo nuovo primo lo adotto con il chip + semplice da fare dopo su quello + complesso.

Praticamente quello che consigli di fare è quello che fa (A grandi linee ovviamene) ATI con le sue VPU da due anni a sta parte??
Cioè...ha trovato una base stabile, solida e valida (leggasi R300) che ha continuato a espandere e a migliorare nel tempo sino all'ultima versione che è l'R420, che (semplificando di molto il concetto) altro non è che un R360 raddoppiato e migliorato in alcune sue parti.
Ho capito bene??

Se si, in effetti non mi sembra una cattiva idea, però mi pare che non si possano espandere all'infinito le varie parti di una CPU, ad esempio mettere 1000 (tanto per dire una cifra) unità FPU, ecc..perchè si arriva al punto in cui i programmi non traggono più giovamento dalle risorse disponibile nella CPU, in quento tali rimarrebero inutilizzate!

Mi pare che le cose stiano più o meno così!

Bye ;)

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... :D



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/semiconductor/article/CA372265?pubdate=1%2F1%2F2004&industryid=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/vita/research/Projects/193nm_lithography.ppt

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.....

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!;)

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! ;)

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).

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.

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!!:muro:

Bye!;)

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.

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...

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

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...

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

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. :D

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.

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.

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. :D

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" :p

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 :D

Ciao

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. :)

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 :D)

Ciao :)

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... :)

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 :D) 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 :D, 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? :D).


Questo, è la mia opinione, chiaramente...

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

Ciao :)

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 :D)
Io mi sto toccando... :D:D:D
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 :D, 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? :D).
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... :D

Ciao :)
:)

Ciao

[...]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... :)


Non mi riferivo alla circuiteria, ma al lavoro che mi pare di aver capito che fanno comunque i compilatori per far giungere al processore del codice già parzialmente ordinato, in modo da avere una buona base di partenza per non perdere troppo tempo nel riordino.

L'estensione potrebbe essere del tipo "devo fare 6 somme indipendenti, più altre operazioni che non influenzano le variabili da sommare, ho a disposizione una cpu con due core e 3 alu per core, quindi raggruppo (durante la compilazione) le somme in due gruppi di istruzioni consecutive, schedulando le altre per un momento successivo, e aggiungo una verifica sulle caratteristiche del processore, così, rilevati i due core, faccio eseguire le sei somme parallelamente con un solo ciclo macchina, sempre che il sistema mi consenta di ottenere il controllo di entrambi i core e che, per motivi contingenti, ciascun core non "decida" di ordinare diversamente il proprio gruppo di istruzioni".

Oppure, cosa in realtà (credo) già fattibile (almeno in parte), uso un linguaggio (con relativo compilatore) che mi consenta, tornando all'esempio dell'immagine da renderizzare, di non dover creare esplicitamente un certo numero di sottoprocessi che elaborino una parte specifica dei dati di partenza, bensì di potermi "limitare" a creare una "unità di lavoro" di base e una o più regole per suddividere il lavoro e ricomporre il risultato (un modello di coordinazione), in modo che il programma risultante riconosca le risorse disponibili e provveda a suddividere il lavoro in maniera opportuna (rispettando le regole imposte). Insomma, rendo il compilatore un po' più intelligente (o anche molto, a seconda di quello che posso fare profiquamente in quel preciso momento "storico") e creo un linguaggio ad hoc per pilotare questa maggiore intelligenza in maniera corretta e con lo sforzo minore possibile; non penso certo di lasciar fare tutto al compilatore, partendo da un sorgente "classico" con struttura sequenziale, per quanto avanzate possano essere le tecniche di IA sfruttabili sarebbe alto il rischio di incasinare tutto (la potenza è nulla senza controllo, ma se puoi controllare con abs, ebd, servosterzo, servofreno, servo_selezionatore_di_autostoppiste_bonazze_da_rimorchiare...:D è meglio, no?)
Chiaramente tutto riferito ad un futuro (più o meno lontano) in cui ciò si possa fare senza grossi problemi, servirebbero progressi anche notevoli nelle tecniche di IA, condicio sine qua non ha senso niente di quello che ho detto.

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

Personalmente sono fiducioso che, risolti i problemi tecnici, un modo si trovi. Se non sbaglio, oggi si potrebbe fare tutto con linguaggi di programmazione logica (tipo prolog o lisp), che in un certo senso sono non deterministici, poichè non seguono una strada univoca, ma valutano diverse strade, interrogando un database o applicando delle regole ai predicati in maniera ricorsiva e con tecniche di branch & bound. Forse con quelle macchine si prediligerà questo stile di programmazione. Staremo a vedere (altra toccatina d'obbligo....:D)

Ciao

Originariamente inviato da xeal
Non mi riferivo alla circuiteria, ma al lavoro che mi pare di aver capito che fanno comunque i compilatori per far giungere al processore del codice già parzialmente ordinato, in modo da avere una buona base di partenza per non perdere troppo tempo nel riordino.
OK, adesso è più chiaro. Questo chiaramente si potrebbe fare, ma non so quanto possa essere efficiente...
L'estensione potrebbe essere del tipo "devo fare 6 somme indipendenti, più altre operazioni che non influenzano le variabili da sommare, ho a disposizione una cpu con due core e 3 alu per core, quindi raggruppo (durante la compilazione) le somme in due gruppi di istruzioni consecutive, schedulando le altre per un momento successivo, e aggiungo una verifica sulle caratteristiche del processore, così, rilevati i due core, faccio eseguire le sei somme parallelamente con un solo ciclo macchina, sempre che il sistema mi consenta di ottenere il controllo di entrambi i core e che, per motivi contingenti, ciascun core non "decida" di ordinare diversamente il proprio gruppo di istruzioni".
Appunto. Ricordi i problemi dell'Itanium: gli manca del tutto l'unità OOO, e le prestazioni sugli interi non è che siano un granché. ;) Il problema è che certe cose è meglio lasciarle decidere alla logica OOO al momento preciso in cui debbono eseguite le istruzioni, valutando tutte le risorse disponibili per portarle al termine in quel preciso momento...
Oppure, cosa in realtà (credo) già fattibile (almeno in parte), uso un linguaggio (con relativo compilatore) che mi consenta, tornando all'esempio dell'immagine da renderizzare, di non dover creare esplicitamente un certo numero di sottoprocessi che elaborino una parte specifica dei dati di partenza, bensì di potermi "limitare" a creare una "unità di lavoro" di base e una o più regole per suddividere il lavoro e ricomporre il risultato (un modello di coordinazione), in modo che il programma risultante riconosca le risorse disponibili e provveda a suddividere il lavoro in maniera opportuna (rispettando le regole imposte).
Se non crei dei sottoprocessi, vuol dire che comunque in hardware devi fornire una logica e relativa interfaccia fra CPU/core che permetta di smistare il lavoro fra le loro risorse. E quindi dei collegamenti MOLTO veloci per poter comunicare fra di loro (stile i famosi Transputer).
Insomma, rendo il compilatore un po' più intelligente (o anche molto, a seconda di quello che posso fare profiquamente in quel preciso momento "storico") e creo un linguaggio ad hoc per pilotare questa maggiore intelligenza in maniera corretta e con lo sforzo minore possibile; non penso certo di lasciar fare tutto al compilatore, partendo da un sorgente "classico" con struttura sequenziale, per quanto avanzate possano essere le tecniche di IA sfruttabili sarebbe alto il rischio di incasinare tutto (la potenza è nulla senza controllo, ma se puoi controllare con abs, ebd, servosterzo, servofreno, servo_selezionatore_di_autostoppiste_bonazze_da_rimorchiare...:D è meglio, no?)
Probabilmente basterebbe un linguaggio tipo Occam.
Chiaramente tutto riferito ad un futuro (più o meno lontano) in cui ciò si possa fare senza grossi problemi, servirebbero progressi anche notevoli nelle tecniche di IA, condicio sine qua non ha senso niente di quello che ho detto.
Gli sviluppi in questo campo ci sono, ma richiedono notevoli sforzi computazionali: l'intelligenza è una brutta bestia... ;)
Personalmente sono fiducioso che, risolti i problemi tecnici, un modo si trovi.
Il fatto è che per risolverli devi sprecare tante di quelle risorse, che alla fine è più conveniente sfruttare la tecnologia attuale (o magari passare alla luce). :D
In questi casi la penso in maniera diametralmonte opposta a ciò che pensava Einstein ("Dio non gioca a dadi"). ;)
Se non sbaglio, oggi si potrebbe fare tutto con linguaggi di programmazione logica (tipo prolog o lisp), che in un certo senso sono non deterministici,
Soltanto il Prolog diciamo che potrebbe esserlo: il lisp è perfettamente deterministico.
poichè non seguono una strada univoca, ma valutano diverse strade, interrogando un database o applicando delle regole ai predicati in maniera ricorsiva e con tecniche di branch & bound. Forse con quelle macchine si prediligerà questo stile di programmazione.
In effetti il Prolog sembra il linguaggio d'elezione per questo tipo di architetture. Comunque, vedi sopra: io rimango scettico sulle possibilità di sfruttamento della meccanica quantistica per questi scopi...
Staremo a vedere (altra toccatina d'obbligo....:D)

Ciao
Finiremo per consumarle... :D

Originariamente inviato da cdimaur
Se non crei dei sottoprocessi, vuol dire che comunque in hardware devi fornire una logica e relativa interfaccia fra CPU/core che permetta di smistare il lavoro fra le loro risorse. E quindi dei collegamenti MOLTO veloci per poter comunicare fra di loro (stile i famosi Transputer).



Non dico di non creare processi, ma di crearne uno di base che possa indifferentemente elaborare tutti i dati, se eseguito su un solo processore, oppure una porzione di essi, replicandosi automaticamente su tutti i processori disponibili, e combinando i risultati parziali (eventualmente rielaborandoli) secondo delle regole che tu hai comunque definito, senza però dover individuare esplicitamente il numero (più conveniente) di processi da creare e i processi che dovranno completare l'elaborazione. Il compilatore provvederà a creare una porzione di codice di controllo che riconosce il numero di processori e replica il processo di base suddividendo la mole di dati da elaborare tra tutti i processi, oltre che alla parte di codice corrispondente alla tua regola di coordinazione. Esempio banale: devo sommare due matrici. Il processo di base sommerà gli elementi corrispondenti di ciascuna matrice per tutti gli elementi che gli vengono assegnati; la parte di controllo verifica il numero di processori disponibili e determina il numero di elementi (e gli elementi stessi) da assegnare a ciascun processo, che sarà eseguito su ciascun processore; la regola di coordinazione sarà semplicemente "spostare i risultati parziali nella locazione di memoria prevista per quell'elemento nel risultato finale" (è la situazione più ottimistica: posso coordinare il calcolo perchè conosco esattamente il risultato finale, noto come coordination by result). Se il processore è unico, verrà creato un solo processo.

Ovviamente più veloci sono le interconnessioni e migliore sarà il risultato (in termini di tempo). D'altra parte, ero partito dal presupposto che l'applicabilità di queste "teorie" va letta in chiave futuristica, per poterne valutare validità e conseguenze (detta così sembra un po' come volersi fasciare la testa prima di averla rotta... :D)



Probabilmente basterebbe un linguaggio tipo Occam

Questo non lo conoscevo ancora.


Gli sviluppi in questo campo ci sono, ma richiedono notevoli sforzi computazionali: l'intelligenza è una brutta bestia...

Altro motivo per spostare la prospettiva di questo discorso anche molto avanti nel tempo.


Quanto allo spreco di risorse con sistemi di calcolo non deterministici, ci sarebbe sotto molti punti di vista. In un certo senso sarebbe come risolvere un problema trattando i dati mediante una codifica non ragionevole, che richiede molto più spazio ma contiene in sè il risultato del problema. Sarebbe come sostituire tutti i numeri reali ad una equazione per risolverla, ma se si potesse fare contemporaneamente si giungerebbe molto rapidamente al risultato. Se gli studi su questi sistemi quantistici conducessero ad un modo per farlo, e si riuscisse a produrre ad un costo accettabile la circuiteria necessaria, che per quanto ho capito dovrebbe essere estremamente "sensibile" e poter assumere un numero elevato di stati, praticamente nello stesso istante, non sarebbe poi così male. Ovvio che oggi possiamo solo accontentarci di quello che abbiamo e magari fingere di non vedere i problemi realizzativi e sognare di poter avere un giorno tra le mani una bestia che esegue i tuoi ordini alla perfezione prima che tu abbia finito di impartirli :D.


Finiremo per consumarle...

Be', allora tocchiamo ferro, almeno quello si può sostituire... :D

Ciao :)

Originariamente inviato da xeal
[...]Ovviamente più veloci sono le interconnessioni e migliore sarà il risultato (in termini di tempo). D'altra parte, ero partito dal presupposto che l'applicabilità di queste "teorie" va letta in chiave futuristica, per poterne valutare validità e conseguenze (detta così sembra un po' come volersi fasciare la testa prima di averla rotta... :D)
OK, già quel che hai scritto non comporterebbe l'utilizzo di molte risorse sia hardware sia software. Comunque, dovresti dare un'occhiata ai Transputer e Occam, perché a naso direi che presentano PARECCHIE similarità... ;)
Quanto allo spreco di risorse con sistemi di calcolo non deterministici, ci sarebbe sotto molti punti di vista. In un certo senso sarebbe come risolvere un problema trattando i dati mediante una codifica non ragionevole, che richiede molto più spazio ma contiene in sè il risultato del problema. Sarebbe come sostituire tutti i numeri reali ad una equazione per risolverla, ma se si potesse fare contemporaneamente si giungerebbe molto rapidamente al risultato. Se gli studi su questi sistemi quantistici conducessero ad un modo per farlo, e si riuscisse a produrre ad un costo accettabile la circuiteria necessaria, che per quanto ho capito dovrebbe essere estremamente "sensibile" e poter assumere un numero elevato di stati, praticamente nello stesso istante, non sarebbe poi così male. Ovvio che oggi possiamo solo accontentarci di quello che abbiamo e magari fingere di non vedere i problemi realizzativi e sognare di poter avere un giorno tra le mani una bestia che esegue i tuoi ordini alla perfezione prima che tu abbia finito di impartirli :D.
Guarda, all'inizio quando sentivo parlare di computer quantistici mi esaltavao; poi ho cominciato a leggere qualcosa sulla meccanica quantistica, e il mio entusiamo si è decisamente ridimensionato. Veramente, mi sembra difficile pensare di sfruttarla per realizzare calcolatori il cui unico limite sarebbe dettato dalla fantasia; mi sembra, appunto, poco realistico. :D

Ok, farò una bella ricerca sui transputer e occam.
Per il resto, credo che potendo tornare indietro nel tempo e mostrare un desktop replacement a chi lavorava con l'ENIAC (che se non ricordo male, tra l'altro usava per i numeri una codifica ridondante a 10 bit per cifra, a causa dell'elevatissimo rumore elettrico, oltre ad essere enorme e lontano anni luce dai transistor) a qualcuno verrebbe un infarto... Probabilmente oggi siamo anni luce, tecnologicamente e forse anche quanto a conoscenze, dal poter realizzare un computer quantistico, se mai si potrà fare, però fantasticare ed esaltarsi sulle prospettive future, ogni tanto, dai che male non fa :D

Ciao :)

Posso assicurarti che sono un tipo a cui la fantasia galoppa molto (alcuni miei amici e mia moglie dicono anche troppo ;)). Qui, magari, mi vedi un po' troppo razionale nell'affrontare i discorsi che si intavolano: deformazione professionale... :p

OK, documentati su transputer e occam, e vedrai che troverai l'argomento interessante. Se conosci qualcuno che conserva dei vecchi numeri di MC Microcomputer, materiale ne troverai a vagonate: pure la famosa rete ADPNetwork per Amiga realizzata, appunto, con delle schede con transputer per lo scambio dei dati... ;)