Link alla notizia: http://www.hwupgrade.it/news/sistemi/taihulight-il-nuovo-supercomputer-piu-veloce-al-mondo-usa-solo-cpu-cinesi_63261.html

Tianhe-2 è stato battuto da un sistema che è ancora "più cinese". Oltre ad essere posizionato in Cina TaihuLight, il nuovo sistema da record, utilizza CPU progettate localmente

Click sul link per visualizzare la notizia.

Cosa che dovrebbe fare pure l'Europa ma, che non accadrà mai, data la frammentazione esistente.

speriamo che arrivi presto anche il primo computer quantistico cinese

speriamo che arrivi presto anche il primo computer quantistico cinese

A me basterebbe un competitor per Intel :D

Ma ci gira Windwos (no Crysys non me frega una fava) :D ?

Comunque a parte le battute queste sono CPU da Super Computer quindi pensare a concorrenza ad Intel non ha senso: quel "mostro" avrà bisogno di alimentatore da 1'000 W, raffreddamento a liquido ecc...

I Russi, invece, hanno in casa qualcosa che in teoria ad Intel potrebbe far paura:

https://en.wikipedia.org/wiki/Elbrus-8S

... sì su quello Windows ci gira :D

Ma lentamente, visto che deve emulare x86.

Comunque Intel non ha nulla da temere.

potreste farci un articolo sullo stato delle alternative a intel per cpu non arm.
qui secoli fa c'erano aggiornamenti su transmeta, so che ci sono alternative russe e indiane, ma non ho capito assolutamente l'ordine di grandezza di queste alternative!

Ma ci gira Windwos (no Crysys non me frega una fava) :D ?

Comunque a parte le battute queste sono CPU da Super Computer quindi pensare a concorrenza ad Intel non ha senso: quel "mostro" avrà bisogno di alimentatore da 1'000 W, raffreddamento a liquido ecc...

I Russi, invece, hanno in casa qualcosa che in teoria ad Intel potrebbe far paura:

https://en.wikipedia.org/wiki/Elbrus-8S

... sì su quello Windows ci gira :D

Supported operating systems

Linux Kernel based OS compiled for Elbrus

No Windows, sorry.

A parte questo, se altri cominciano a fare chip in casa anche per supercomputer si mette male per Intel. Soprattutto perché anche questo, come fu per il Cell, consuma meno di 1/3 per la stessa potenza computazionale. E non credo che siano fatti con il migliore PP.
Altra dimostrazione ch ciò che ha permesso ad Intel di sooravanzare tutti i concorrenti è stato per via del PP migliore, non certo per l'efficienza dell'architettura. Ora che il vantaggio del PP è praticamente andato, andato è il vantaggio tecnologico di Intel. Le rimane il mercato dipendente da Windows e il fattore di scala che le permette di sfornare chip che le costano meno della concorrenza a parità di area.
In attesa dei chip server ARM based con I quali anche questo vantaggio se ne andrà e rimarrà solo la dipendenza dal mercato Windows. Che non è certo piccolo, ma le crepe anche in quello si sono già aperte.

A parte questo, se altri cominciano a fare chip in casa anche per supercomputer si mette male per Intel. Soprattutto perché anche questo, come fu per il Cell, consuma meno di 1/3 per la stessa potenza computazionale. E non credo che siano fatti con il migliore PP.
Il problema dei supercomputer fatti in casa dai cinesi è dovuto principalmente all'embargo imposto dagli USA.
Altra dimostrazione ch ciò che ha permesso ad Intel di sooravanzare tutti i concorrenti è stato per via del PP migliore, non certo per l'efficienza dell'architettura. Ora che il vantaggio del PP è praticamente andato, andato è il vantaggio tecnologico di Intel.
Permettimi: questo NUOVO supercomputer ha il TRIPLO dei core del precedente basato su Xeon Phi (Knights Corner). Lo credo bene che abbia il triplo delle prestazioni...

Quanto al processo produttivo non mi pare ci siano informazioni, a parte su Knights Corner, che però ne usa uno ormai vecchio (22nm).

Knights Landing rimetterà le cose in sesto.
Le rimane il mercato dipendente da Windows e il fattore di scala che le permette di sfornare chip che le costano meno della concorrenza a parità di area.
Dovresti informarti: la maggior parte del fatturato di Intel arriva ormai da tempo da mercati non-Windows.
In attesa dei chip server ARM based con I quali anche questo vantaggio se ne andrà e rimarrà solo la dipendenza dal mercato Windows. Che non è certo piccolo, ma le crepe anche in quello si sono già aperte.
Articolo abbastanza fresco da parte di AnandTech proprio su questo tema: Investigating Cavium's ThunderX: The First ARM Server SoC With Ambition (http://www.anandtech.com/show/10353/investigating-cavium-thunderx-48-arm-cores)

"When is a worthy alternative to Intel's Xeon finally going to appear? That is the burning question in the server world. If PowerPoint presentations from various ARM-based SoCs designers released earlier this decade were to be believed, Intel would now be fighting desperately to keep a foothold in the low end server market. But the ARM SoCs so far have always disappointed: the Opteron A1100 was too late, the X-Gene 1 performed poorly, consumed too much power, and Broadcomm's Vulcan project is most likely dead.
[...]
Meanwhile, Intel listened to their "hyperscaler customers" (Facebook, Google...) and delivered the Xeon D. We reviewed Intel's Broadwell SoC and we had to conclude that this was one of the best products that Intel made in years. It is set a new performance per watt standard and integrated a lot of I/O. The market agreed: Facebook's new web farms were built upon this new platform, ARM servers SoCs were only successful in the (low end) storage server world. To make matter worse, Intel expanded the Xeon D line with even higher performing 12 and 16 core models.
[...]
The Xeon D, by comparison, offers superior performance per watt: twice as good as the ThunderX. It is clear that the ThunderX is not a good match for heavy database servers, nor for enterprise workloads where energy consumption at low load is a high priority.
[...]
We found out that the raw integer computing power of the Thunder-X is about one-third that of the best Xeon Ds, not one-fifth as claimed in advertising materials (a difference of 65%). The ThunderX core is almost as good as the A57, while it consumes quite a bit less power and thus offers a better performance-per-watt than the latter. "

Supported operating systems

Linux Kernel based OS compiled for Elbrus

No Windows, sorry.


Certo che ci gira Windows è in grado di eseguire anche codice x86 con instruction decoder che traduce nelle sue VLIW interne ovvero quella CPU può eseguire due instruction set x86 e il suo interno... un po' come faceva Itanium (ma si spera con performance migliori!).


In attesa dei chip server ARM based con I quali anche questo vantaggio se ne andrà e rimarrà solo la dipendenza dal mercato Windows. Che non è certo piccolo, ma le crepe anche in quello si sono già aperte.

Windows storicamente non è solo Intel esistero porting per RISC, SPARC, Alpha, Itanium il problema era che tutti questi XP non facevano girare il codeice x86 che ci porta dietro da 30 anni e passa!

Ciò basta pagare e la Microsoft te lo porta al volo...

Maggiori dettagli sul nuovo supercomputer e sulle sue cpu:
http://www.hpcwire.com/2016/06/19/china-125-petaflops-sunway/

Ma è da notare che il NIST è molto più avanti, basta vedere la loro ultima generazione di simulatori quantistici (dei "computer quantistici dedicati") che letteralmente spazza via i supercomputer nelle simulazioni di materiali e metamateriali:
http://www.nist.gov/pml/div688/qubits-042512.cfm

E notare che se il NIST rende pubblica roba simile, significa che l'NSA come al solito è MOLTO più avanti in tal senso (specialmente se si parla di crittografia e cose simili).

Sempre in tema di supercomputer, sembra che per la prossima generazione di supercomputer ISC Fujitsu abbandonerà gli Sparc64 per passare agli ARMv8:
http://www.theregister.co.uk/2016/06/20/fujitsu_arm_supercomputer/

Per il 2020 pensano di aver pronto un sistema da 1000 PFLOPS.

ed e' cosi' che la prima superpotenza mondiale scopri' di essere "indietro" sull' AI!

Certo che ci gira Windows è in grado di eseguire anche codice x86 con instruction decoder che traduce nelle sue VLIW interne ovvero quella CPU può eseguire due instruction set x86 e il suo interno... un po' come faceva Itanium (ma si spera con performance migliori!).
Rispetto al primo Itanium sicuramente, ma considerato che Transmeta, che aveva un'architettura VLIW appositamente orientata alla traduzione & esecuzione di codice "alieno" (x86 ovviamente), aveva scarse prestazioni, da un VLIW che ha istruzioni ancora più lunghe mi aspetto di peggio.
Windows storicamente non è solo Intel esistero porting per RISC, SPARC, Alpha, Itanium il problema era che tutti questi XP non facevano girare il codeice x86 che ci porta dietro da 30 anni e passa!

Ciò basta pagare e la Microsoft te lo porta al volo...
Esatto, ma sono anni che non lo fa più.
Maggiori dettagli sul nuovo supercomputer e sulle sue cpu:
http://www.hpcwire.com/2016/06/19/china-125-petaflops-sunway/

Ma è da notare che il NIST è molto più avanti, basta vedere la loro ultima generazione di simulatori quantistici (dei "computer quantistici dedicati") che letteralmente spazza via i supercomputer nelle simulazioni di materiali e metamateriali:
http://www.nist.gov/pml/div688/qubits-042512.cfm

E notare che se il NIST rende pubblica roba simile, significa che l'NSA come al solito è MOLTO più avanti in tal senso (specialmente se si parla di crittografia e cose simili).
Dubito che i computer quantistici infastidiranno quelli tradizionali.

Inoltre anche nel loro campo applicativo i dubbi rimangono.
Sempre in tema di supercomputer, sembra che per la prossima generazione di supercomputer ISC Fujitsu abbandonerà gli Sparc64 per passare agli ARMv8:
http://www.theregister.co.uk/2016/06/20/fujitsu_arm_supercomputer/

Per il 2020 pensano di aver pronto un sistema da 1000 PFLOPS.
Toh, un altro RISC (SPARC) sulla via del tramonto. :D
ed e' cosi' che la prima superpotenza mondiale scopri' di essere "indietro" sull' AI!
Non vedo come / perché.

TaihuLight utilizza 40.960 mila chip


cifre all'ingegner cane? È un punto o una virgola?

poi

Sono 40.960 i nodi che compongono l'intero sistema con un picco massimo di potenza che può arrivare a 125 petaflop, e con 93 petaflop su Linpack abbiamo una rispettabilissima resa del 74% rispetto al massimo teorico.


manca un mille mila, a sto punto.

Su altre testate online un pò più "specializzate" avevano postato quest'articolo a proposito del fatto che i cinesi avessero utilizzato tale tipo di sistema a sfavore di quello dei "'muricans"

http://boingboing.net/2016/06/15/intel-x86-processors-ship-with.html

Per il 2020 pensano di aver pronto un sistema da 1000 PFLOPS.

All'inizio pensavano di arrivare all'exaflops nel 2016.
Poi è diventato il 2018.
Adesso il 2020.
Non è per niente facile arrivare a quel numeretto.

Ci vorrebbero davvero i cinesi a fare concorrenza allo strapotere Intel, come fece AMD a fine anni '90 (ora è il nulla assoluto purtroppo). Tra un paio di anni per comprare una CPU di fascia medio/alta bisognerà vendere un rene.

Fare il triplo delle prestazioni del secondo in classifica è notevole, ma lo è ancor di più col 16% dei consumi in meno.

Permettimi: questo NUOVO supercomputer ha il TRIPLO dei core del precedente basato su Xeon Phi (Knights Corner). Lo credo bene che abbia il triplo delle prestazioni...
Ma chissene. Scusa se il triplo dei core cinesi consumano meno di quello che fino a ieri era il gioiello Intel andando il TRIPLO.
Quel che conta sono i FLOPS x W e qui non c'è troppa per gatti.
E no, neanche con l'ultimo PP di Intel i consumi diventano un terzo. Mi spiace. Forse se i cinesi stanno fermi per un paio di anni e Intel fa i 10nm decenti. Forse eguaglia. Forse.


Quanto al processo produttivo non mi pare ci siano informazioni, a parte su Knights Corner, che però ne usa uno ormai vecchio (22nm).

Knights Landing rimetterà le cose in sesto..
Spiacente, ma Knights landing è già piuttosto dietro Pascal in FLOPS x W nonostante l'uso dei 14nm... Ed era logico aspettarselo, dato che i 22nm di Intel andavano come i 28nm di nvidia. Con 2 pp così simili solo un miracolo avrebbe portato Intel in vantaggio.
Sarà per il prossimo pp, se arriva prima della concorrenza. Incrocia le dita.

Ma chissene. Scusa se il triplo dei core cinesi consumano meno di quello che fino a ieri era il gioiello Intel andando il TRIPLO.
Quel che conta sono i FLOPS x W e qui non c'è troppa per gatti.
E no, neanche con l'ultimo PP di Intel i consumi diventano un terzo. Mi spiace. Forse se i cinesi stanno fermi per un paio di anni e Intel fa i 10nm decenti. Forse eguaglia. Forse.


Spiacente, ma Knights landing è già piuttosto dietro Pascal in FLOPS x W nonostante l'uso dei 14nm... Ed era logico aspettarselo, dato che i 22nm di Intel andavano come i 28nm di nvidia. Con 2 pp così simili solo un miracolo avrebbe portato Intel in vantaggio.
Sarà per il prossimo pp, se arriva prima della concorrenza. Incrocia le dita.

Stai sorvolando alcuni dettagli non di poco conto..stai confrontando la potenza di questo TaihuLight, appena realizzato, con il Tianhe-2, che utilizza processori intel. Potrebbe sembrarti poco, ma Tianhe-2 ha più di due anni. Non sono stati costruiti insieme quindi, che cosa stai confrontando? Aggiungi anche che qui parliamo di processori cinesi costruiti ad-hoc, con un ISA probabilmente molto specializzata. Considerando l'enorme versatilità che notoriamente fa perdere molto ai processori Intel, direi che questi processori sono tutt'altro che miracolosi. Aggiungo inoltre che passare da 17,8 a 15,3 megawatt/ora è moolto diverso dal tuo "un terzo"..consumerà circa un settimo in meno, valore di certo in linea con un evoluzione di due anni. In ogni caso, non male. Ma da qui a dire che Intel è superata, troppa strada devono fare.

Ma chissene. Scusa se il triplo dei core cinesi consumano meno di quello che fino a ieri era il gioiello Intel andando il TRIPLO.
Su questo ti hanno già risposto: ci mancherebbe che non fossero in vantaggio con un'architettura realizzata appositamente, e che in grado di lavorare bene con quel tipo di carichi.
Quel che conta sono i FLOPS x W e qui non c'è troppa per gatti.
I FLOPS da soli non dicono proprio niente, specialmente in sistemi complessi come un supercomputer. Ma rispondo meglio sotto.
E no, neanche con l'ultimo PP di Intel i consumi diventano un terzo. Mi spiace. Forse se i cinesi stanno fermi per un paio di anni e Intel fa i 10nm decenti. Forse eguaglia. Forse.
Ecco qui (http://ark.intel.com/products/codename/48999/Knights-Landing?q=Knights%20Landing) i dati di Knights Landing.

Si arriva a 260W per 6TFLOPS a precisione singola e 3 a precisione doppia, sfruttando i 14nm, ma soprattutto parliamo di CPU su socket e non su schede PCI-Express, con 16GB di memoria embedded direttamente accessibili.
Spiacente, ma Knights landing è già piuttosto dietro Pascal in FLOPS x W nonostante l'uso dei 14nm... Ed era logico aspettarselo, dato che i 22nm di Intel andavano come i 28nm di nvidia. Con 2 pp così simili solo un miracolo avrebbe portato Intel in vantaggio.
Sarà per il prossimo pp, se arriva prima della concorrenza. Incrocia le dita.
Intanto Pascal non mi pare sia stato commercializzato, mentre Knights Landing sì (vedi sopra). Inoltre, come già detto, il primo è su scheda PCI-Express (come Knights Corner) e con tutti i limiti del caso (scambiarsi i dati fra CPU e PCI-Express introduce non poche problematiche, e riduce l'efficienza del sistema), mentre quest'ultimo su socket e ci gira qualunque s.o. (Windows incluso) e qualunque applicazione x86/x64.

Questo significa che OGGI, non domani, puoi prendere qualunque applicazione multithreaded e farla girare senza alcuna modifica su Knights Landing, sfruttando i core e thread hardware a disposizione.

Ovviamente per sfruttarlo al meglio servirebbe una ricompilazione, per avere binari in grado si sfruttare le nuove AVX-512, ma è roba che si fa semplicemente e velocemente, al contrario delle GPU di nVidia che richiedono codice ad hoc con CUDA, che non è certo una passeggiata da realizzare.

Questo per sottolineare ulteriormente che parlare astrattamente di FLOPS, quando il mondo reale funziona diversamente, lascia il tempo che trova...

Stai sorvolando alcuni dettagli non di poco conto..stai confrontando la potenza di questo TaihuLight, appena realizzato, con il Tianhe-2, che utilizza processori intel. Potrebbe sembrarti poco, ma Tianhe-2 ha più di due anni. Non sono stati costruiti insieme quindi, che cosa stai confrontando? Aggiungi anche che qui parliamo di processori cinesi costruiti ad-hoc, con un ISA probabilmente molto specializzata. Considerando l'enorme versatilità che notoriamente fa perdere molto ai processori Intel, direi che questi processori sono tutt'altro che miracolosi. Aggiungo inoltre che passare da 17,8 a 15,3 megawatt/ora è moolto diverso dal tuo "un terzo"..consumerà circa un settimo in meno, valore di certo in linea con un evoluzione di due anni. In ogni caso, non male. Ma da qui a dire che Intel è superata, troppa strada devono fare.
*
Vabbe' ... non ha senso dire che una cpu X e' meglio della cpu Y perche' in alcune applicazioni eroga piu' FLOPS (in questo caso penso sia algebra lineare). Questo processore e' stato costruito appositamente per fare calcoli massicciamente paralleli di un certo tipo. Per il calcolo generico e in single thread, probabilmente queste cpu fanno pena.
*

Aggiungo il link a un paper (http://www.netlib.org/utk/people/JackDongarra/PAPERS/sunway-report-2016.pdf) sull'architettura di questo supercomputer, e della CPU utilizzata.

Com'è possibile notare, i core che macinano i dati hanno una cache L1 di appena 16KB, mentre non c'è una vera e propria cache dati L1. Inoltre non hanno nessuna cache L2/L3/L4.

Questo per evidenziare come si tratti di una soluzione estremamente personalizzata, e disegnata apposta per il tipo di problemi che devono essere risolti dai supercomputer.

Di general purpose, insomma, ha ben poco. Al contrario di soluzioni come Knights Landing che, sebbene non brillino per i calcoli general purpose, sono in grado di generare risultati di tutto rispetto (i core sono basati sull'architettura Silvermont, sebbene con un bel po' di modifiche).

Ci vorrebbero davvero i cinesi a fare concorrenza allo strapotere Intel, come fece AMD a fine anni '90 (ora è il nulla assoluto purtroppo). Tra un paio di anni per comprare una CPU di fascia medio/alta bisognerà vendere un rene.
Come mai nessuno s'è lamentato quando lo strapotere era di IBM, che stradominava la classifica dei supercomputer?

Su altre testate online un pò più "specializzate" avevano postato quest'articolo a proposito del fatto che i cinesi avessero utilizzato tale tipo di sistema a sfavore di quello dei "'muricans"

http://boingboing.net/2016/06/15/intel-x86-processors-ship-with.html
Questo link non ha nulla a che vedere con supercomputer et similia.

*

*

Aggiungo il link a un paper (http://www.netlib.org/utk/people/JackDongarra/PAPERS/sunway-report-2016.pdf) sull'architettura di questo supercomputer, e della CPU utilizzata.

ho letto tutto il documento anche se tempo fa lo avevo gia intravisto, ma mi ricordavo bene alla fine i cinesi sul document hanno scritto che le perfomace della nuova scheda intel sono superiori alla loro implementazione 6 Gflops/W cina contro 9 di quella intel, quindi ora si possono vantare fino a quando avremo un nuovo supercomputer con questa scheda intel e li torneremo a geraggiare ad armi pari senza considerare che l'implementazione intel è piu versatite ed espandibile.

Già. Da notare, poi, come il sistema sia fortemente sbilanciato:

"The ratio of floating point operations per byte of data from memory on the SW26010 is 22.4 Flops(DP)/Byte transfer, which shows an imbalance or an overcapacity of floating point operations per data transfer from memory. By comparison the Intel Knights Landing processor with 7.2 Flops(DP)/Byte transfer. So for many “real” applications the performance on the TaihuLight will be no where near the peak performance rate."

Li voglio vedere gli sviluppatori a lavorare a codice diverso da quello per cui è stato progettato questo chip.

La flessibilità si paga, è vero, ma è anche un gran bel valore aggiunto, e da questo punto di vista non ci sono né chip cinesi né GPU che tengano. ;)

Questo link non ha nulla a che vedere con supercomputer et similia.

Se non ti interessa semplicemente non quotarmi ;)

Se non ti interessa semplicemente non quotarmi ;)
Avevi scritto questo:

"Su altre testate online un pò più "specializzate" avevano postato quest'articolo a proposito del fatto che i cinesi avessero utilizzato tale tipo di sistema a sfavore di quello dei "'muricans""

e aggiunto dopo il link che, come già detto, non ha nulla a che vedere con la notizia di questo supercomputer cinese.

Non è questione che non m'interessi il tuo commento: è che non capisco cosa c'entri con la notizia.

Avevi scritto questo:

"Su altre testate online un pò più "specializzate" avevano postato quest'articolo a proposito del fatto che i cinesi avessero utilizzato tale tipo di sistema a sfavore di quello dei "'muricans""

e aggiunto dopo il link che, come già detto, non ha nulla a che vedere con la notizia di questo supercomputer cinese.

Non è questione che non m'interessi il tuo commento: è che non capisco cosa c'entri con la notizia.

Tanto meglio, se non capisci a cosa si riferisca il link che ho riportato perchè dici che non c'entra?

Quel link l'avevo già letto ben prima che tu lo riportassi.

Non credo sia pertinente al supercomputer oggetto della notizia. Hai motivi a favore?

Dubito che i computer quantistici infastidiranno quelli tradizionali.

Inoltre anche nel loro campo applicativo i dubbi rimangono.

Ma molto probabilmente si ritaglieranno una loro nicchia, per chiunque si sia interessato un minimo alla cosa è ovvio che i vantaggi di sistemi di calcolo quantistici sono limitati a classi specifiche di problemi, infatti quelli del NIST lo descrivono come un simulatore invece che come un sistema di calcolo generico.
Ma proprio per le tipologie di problemi che possono attaccare (in certi casi letteralmente) hanno un vantaggio enorme nei confronti dei supercomputer "classici".

Toh, un altro RISC (SPARC) sulla via del tramonto. :D

Un vecchio (più o meno) RISC che fa spazio ad un nuovo (più o meno) RISC, semmai. ;)

ARMv8 è abbastanza nuova come architettura, ma della stessa famiglia ARM. Come x64 lo è di IA-32, per intenderci.

Riguardo ai computer quantistici, a livello teorico hanno un enorme vantaggio nel loro dominio applicativo, ma il problema principale rimane trasferire loro le montagne di dati da processare, e ricevere indietro i risultati dell'elaborazione. Cosa tutt'altro che banale, visto le condizioni in cui operano.

Per essere chiari, me ne faccio poco di un computer quantistico in grado di selezionare "istantaneamente" i dati che mi servono da un database gigantesco, quando il trasferimento di quest'ultimo a tale computer richiede ere geologiche.

ARMv8 è abbastanza nuova come architettura, ma della stessa famiglia ARM. Come x64 lo è di IA-32, per intenderci.

La modalità a 64bit degli ARMv8 è più simile al set d'istruzioni delle cpu Alpha con estensioni SIMD che a quello ARM a 32bit.

Inoltre una cpu "full" ARMv8 prevede la modalità a 64bit (AArch64 o A64), la modalità a 32bit (AArch32 o A32) ed infine la modalità Thumb (T32).

Ma nulla vieta di realizzare una cpu con solo la AArch64 (e penso che per le cpu da supercomputer faranno così) per ridurre al minimo i gate utilizzati
( se non sbaglio i decoder A32 e T32 se li si lascia disattivati non incidono sulle prestazioni, ma stanno li ad occupare spazio se nessuno li usa).


Riguardo ai computer quantistici, a livello teorico hanno un enorme vantaggio nel loro dominio applicativo, ma il problema principale rimane trasferire loro le montagne di dati da processare, e ricevere indietro i risultati dell'elaborazione. Cosa tutt'altro che banale, visto le condizioni in cui operano.

Per essere chiari, me ne faccio poco di un computer quantistico in grado di selezionare "istantaneamente" i dati che mi servono da un database gigantesco, quando il trasferimento di quest'ultimo a tale computer richiede ere geologiche.

Per questo quelli del NIST vengono classificati come "simulatori" (relativamente pochi dati in ingresso ed uscita, il grosso dei dati temporanei elaborati è implicitamente in forma quantistica).

Ed è per questo che sono, e probabilmente continueranno a essere, estremamente limitati.

Sì, credo che i decoder A32 e T32 possano essere spenti in modalità A64, un po' come si possono spegnere le ALU inutilizzate, ma non sono un esperto in questo settore.

Certamente ha senso realizzare delle apposite versioni che supportino soltanto l'ISA A64 (e lo stesso per x86. Ad esempio il vecchissimo 80396 di Intel, se non ricordo male il codice, supporta soltanto la modalità protetta a 32 bit).

Comunque A64 è anche largamente compatibile (a livello di istruzioni) con A32. Sono state rimosse quasi tutte le istruzioni condizionate (altrimenti sarebbe stato impossibile trovare lo spazio per i 3 o 4 bit necessari per codificare i 16 registri aggiunti), e quelle che operano su più registri (a parte un paio speciali di load/store che caricano e salvano 2 registri alla volta), ma per il resto c'è sostanzialmente tutto. E l'unità SIMD NEON, in particolare, dovrebbe essere rimasta la stessa a livello di istruzioni (con qualche aggiunta rispetto ad ARMv7), ma con più registri.

Cosa che dovrebbe fare pure l'Europa ma, che non accadrà mai, data la frammentazione esistente.
Penso che il problema sia più la subalternità strategica agli Stati Uniti che la frammentazione.

Comunque A64 è anche largamente compatibile (a livello di istruzioni) con A32. Sono state rimosse quasi tutte le istruzioni condizionate (altrimenti sarebbe stato impossibile trovare lo spazio per i 3 o 4 bit necessari per codificare i 16 registri aggiunti), e quelle che operano su più registri (a parte un paio speciali di load/store che caricano e salvano 2 registri alla volta), ma per il resto c'è sostanzialmente tutto. E l'unità SIMD NEON, in particolare, dovrebbe essere rimasta la stessa a livello di istruzioni (con qualche aggiunta rispetto ad ARMv7), ma con più registri.

Si e no.
Non è come succede con gli x86-64 ed i prefissi per selezionare registri aggiuntivi ecc.

Il set d'istruzioni A64 è in larga parte SEMANTICAMENTE compatibile con A32
(la "sintassi dell' assembly è quasi uguale" e la semantica delle istruzioni è quasi la stessa
eccetto che per il numero di registri interni e la loro dimensione).

La codifica binaria del set d'istruzioni e la struttura del decoder invece sono stati riscritti da zero.

Infatti in modalità A64 i registri SIMD raddoppiano di dimensione e numero
rispetto alla versione a 32bit e le relative istruzioni diventano parte integrante
del set d'istruzioni a 64bit (codificato su word di lunghezza fissa a 32bit, ma con mappatura e codifica diversa da A32).

Gli indici dei registri sono a 5bit "tutti vicini" (senza contorsionismi strani con prefissi di istruzione come sugli x86-64) ed inoltre solo R0..R30 sono "veri" registri mentre quello che nella codifica corrisponderebbe ad R31 è la costante zero oppure lo stack pointer
in base al tipo di istruzione.

Inoltre il numero di registri interni e SIMD, il registro "costante zero" ed altre feature architetturali di A64 ricordano le cpu Alpha, altre
come la "dualità" di R31 invece sono basate su analisi ex-novo del codice tipicamente eseguito e relativa ottimizzazione del decoder.

I prefissi condizionali "per tutte le istruzioni"
(sempre in base alle analisi di "costo"/"efficienza")
sono stati abbandonati perchè su una cpu a 64bit moderna
di solito ci sono sufficienti gate a disposizione per implementare la jump prediction
e cache L1 ed L2 sufficientemente ampie che vale la pena rendere condizionali
solo un numero ridotto di istruzioni che traggono davvero vantaggio della cosa
(in modo speculare a come era successo con le estensioni Thumb in cui
la motivazione primaria era che la compattezza del set d'istruzioni era più importante
di altri fattori).

Notare anche che i core ARMv8 più recenti magari non sono all'altezza
dei core x86 "da desktop/server" ma sono decisamente in grado di dare battaglia
ai core Atom più recenti e loro varianti (incluse quelle usate ad esempio sugli Xeon Phi "Knights Landing").

In teoria le estensioni SIMD AVX-512 dovrebbero avvantaggiare comunque Knights Landing ed evoluzioni successive quando ci sono da fare elaborazioni di matrici e cose simili (grafica, ecc.), ma quando si supera un certo numero di core per chip la banda di I/O disponibile, la dimensione delle cache ai vari livelli e la granularità dei dati e del codice potrebbero annullare tale "vantaggio".

Si e no.
Non è come succede con gli x86-64 ed i prefissi per selezionare registri aggiuntivi ecc.

Il set d'istruzioni A64 è in larga parte SEMANTICAMENTE compatibile con A32
(la "sintassi dell' assembly è quasi uguale" e la semantica delle istruzioni è quasi la stessa
eccetto che per il numero di registri interni e la loro dimensione).

La codifica binaria del set d'istruzioni e la struttura del decoder invece sono stati riscritti da zero.

Infatti in modalità A64 i registri SIMD raddoppiano di dimensione e numero
rispetto alla versione a 32bit e le relative istruzioni diventano parte integrante
del set d'istruzioni a 64bit (codificato su word di lunghezza fissa a 32bit, ma con mappatura e codifica diversa da A32).

Gli indici dei registri sono a 5bit "tutti vicini" (senza contorsionismi strani con prefissi di istruzione come sugli x86-64) ed inoltre solo R0..R30 sono "veri" registri mentre quello che nella codifica corrisponderebbe ad R31 è la costante zero oppure lo stack pointer
in base al tipo di istruzione.

Inoltre il numero di registri interni e SIMD, il registro "costante zero" ed altre feature architetturali di A64 ricordano le cpu Alpha, altre
come la "dualità" di R31 invece sono basate su analisi ex-novo del codice tipicamente eseguito e relativa ottimizzazione del decoder.
Non ho avuto modo di vedere la struttura della opcode table di A64, ma dai cambiamenti effettuati immaginavo già che fosse stata ridisegnata.

D'altra parte di tempo ne hanno avuto per fare un buon lavoro per la nuova architettura a 64 bit, al contrario di x64 che è stato velocemente modellato sulla stessa base di IA-32.
I prefissi condizionali "per tutte le istruzioni"
(sempre in base alle analisi di "costo"/"efficienza")
sono stati abbandonati perchè su una cpu a 64bit moderna
di solito ci sono sufficienti gate a disposizione per implementare la jump prediction
e cache L1 ed L2 sufficientemente ampie che vale la pena rendere condizionali
solo un numero ridotto di istruzioni che traggono davvero vantaggio della cosa
Non so questo quanto possa essere vero, visto che uno dei vantaggi dell'architettura ARM era proprio quello di eseguire codice condizionato senza dover ricaricare la pipeline in caso di predizione errata. Ci sono tanti casi in cui il codice produce salti non predicibili dal predittore (ad esempio il ciclo principale dell'interprete Python, dove viene decodificata l'istruzione da eseguire, che può essere con o senza argomento), e dove le istruzioni condizionati fanno la differenza.

Ovviamente questo meccanismo funziona solo quando i due rami di codice condizionati sono abbastanza piccoli (ben sotto la lunghezza della pipeline come numero di istruzioni eseguite in totale), altrimenti ha molto più senso il classico salto.

C'è, insomma, un trade-off, com'è ovvio che sia, e che dipende dalla lunghezza della pipeline.

Entrambi i meccanismi hanno pregi e difetti, come sempre, ma le istruzioni condizionate, sebbene eleganti, mangiano troppo spazio nella opcode table, e se non ricordo male creano un po' di problemi nel backend.
(in modo speculare a come era successo con le estensioni Thumb in cui
la motivazione primaria era che la compattezza del set d'istruzioni era più importante
di altri fattori).
La compattezza del codice lo è ancora, ma il problema è che A64 non ha lasciato spazio per una versione adattata a 64 bit di Thumb-2.

Si potrebbe sempre realizzarne una ad hoc, ma con notevoli compromessi, e senza la possibilità di eseguire tutte le istruzioni A64 (mentre con Thumb-2 è possibile farlo, senza però la condizione applicabile a ogni istruzione A32: è grazie a questo che è stato recuperato spazio per introdurre gli opcode a 16 bit).

Forse è per questo che ARM non ha ancora presentato un'ISA compatta a 64-bit, nonostante siano passati ormai diversi anni dall'introduzione di A64.
Notare anche che i core ARMv8 più recenti magari non sono all'altezza
dei core x86 "da desktop/server" ma sono decisamente in grado di dare battaglia
ai core Atom più recenti e loro varianti (incluse quelle usate ad esempio sugli Xeon Phi "Knights Landing").
I core Atom più recenti eseguono al massimo 2 istruzioni out-of-order per ciclo di clock.

Esistono microarchitetture ARMv8 con pipeline simili e che siano di produrre prestazioni migliori?
In teoria le estensioni SIMD AVX-512 dovrebbero avvantaggiare comunque Knights Landing ed evoluzioni successive quando ci sono da fare elaborazioni di matrici e cose simili (grafica, ecc.),
Esattamente: sono nate proprio per questo, ed hanno una notevole flessibilità ed eleganza (vedi la gestione delle maschere e il broadcasting dei dati).
ma quando si supera un certo numero di core per chip la banda di I/O disponibile, la dimensione delle cache ai vari livelli e la granularità dei dati e del codice potrebbero annullare tale "vantaggio".
Se guardi le soluzioni basate su core RISC, hanno molti più core di Knights Landing, e dunque ciò che affermi pesa ancora di più per loro che a quest'ultimo.

Un esempio è proprio l'architettura di questo supercomputer che, come riportato, è fortemente sbilanciata da questo punto di vista: 22.4 Flops(DP)/Byte transfer.

Mentre Knights Landing presenta un 7.2 Flops(DP)/Byte, e dunque soffre di gran lunga meno la (mancanza di) banda. ;)

Non so questo quanto possa essere vero, visto che uno dei vantaggi dell'architettura ARM era proprio quello di eseguire codice condizionato senza dover ricaricare la pipeline in caso di predizione errata. Ci sono tanti casi in cui il codice produce salti non predicibili dal predittore (ad esempio il ciclo principale dell'interprete Python, dove viene decodificata l'istruzione da eseguire, che può essere con o senza argomento), e dove le istruzioni condizionati fanno la differenza.

Per questo oltre ai branch condizionali l'ISA A64 ha istruzioni "move", "compare", "increment", "negate" e "not" condizionali.
Con quelle coprono quasi tutti i casi in cui l'esecuzione condizionale ha senso
oppure in cui è difficile predire il branch (oltre ad eliminare la maggior parte dei branch molto corti, rendendo in generale più efficiente la branch prediction).


La compattezza del codice lo è ancora, ma il problema è che A64 non ha lasciato spazio per una versione adattata a 64 bit di Thumb-2.
Le estensioni Thumb sono usate per migliorare la compattezza del codice
su sistemi embedded e/o per ridurre i gate nei core arm "minimali" tipo M0 o M1.
Avrebbero poco senso su un sistema a 64bit (che implicitamente ha molta cache, molta memoria e banda di I/O a disposizione rispetto ad un sistema embedded di fascia "bassa").
Se si esegue codice per una tipica applicazione "pesante" generato da un compilatore decente, il codice A64 è già sufficientemente compatto di suo anche rispetto ad x86-64.


I core Atom più recenti eseguono al massimo 2 istruzioni out-of-order per ciclo di clock.

Esistono microarchitetture ARMv8 con pipeline simili e che siano di produrre prestazioni migliori?

Il decoder dei Cortex A57 lancia in esecuzione 3 istruzioni per ciclo con fino a 128 micro-op in fase di esecuzione e fino ad 8 micro-op in esecuzione simultanea per ciclo.

Mentre l'A72 ha il decoder sempre da 3 istruzioni per ciclo, ma che vengono espanse fino a 5 micro-op simultanee (rispetto ad A57 hanno strutturato in modo diverso le unita di esecuzione ed aumentato la granularità delle micro-op).
Nella presentazione fatta da ARM Ltd. lo confrontano più con i Core M che con gli Atom:
http://cdn.arstechnica.net/wp-content/uploads/2015/04/cortex-a72-vs-core-m-broadwell.png

Se guardi le soluzioni basate su core RISC, hanno molti più core di Knights Landing, e dunque ciò che affermi pesa ancora di più per loro che a quest'ultimo.

Un esempio è proprio l'architettura di questo supercomputer che, come riportato, è fortemente sbilanciata da questo punto di vista: 22.4 Flops(DP)/Byte transfer.

Mentre Knights Landing presenta un 7.2 Flops(DP)/Byte, e dunque soffre di gran lunga meno la (mancanza di) banda. ;)

Se sia un vantaggio oppure no dipende dal tipo di codice che viene eseguito e dall'architettura "completa" che si ottiene alla fine.
Per questo alla fine più che i benchmark contano le prestazioni effettive che sia hanno nel campo di utilizzo specifico.

Per questo oltre ai branch condizionali l'ISA A64 ha istruzioni "move", "compare", "increment", "negate" e "not" condizionali.
Con quelle coprono quasi tutti i casi in cui l'esecuzione condizionale ha senso
oppure in cui è difficile predire il branch (oltre ad eliminare la maggior parte dei branch molto corti, rendendo in generale più efficiente la branch prediction).
Purtroppo non sono abbastanza. Ad esempio nel caso di CPython devi estrarre l'argomento, se è presente, e non puoi farlo con quelle istruzioni. Scenari del genere si ritrovano con virtual machine ed emulatori, e quindi non sono così comuni.

Certamente è un gran passo avanti rispetto ad avere soltanto CMOV e SET (che però è più comoda) di x86/x86-64.
Le estensioni Thumb sono usate per migliorare la compattezza del codice
su sistemi embedded e/o per ridurre i gate nei core arm "minimali" tipo M0 o M1.
Avrebbero poco senso su un sistema a 64bit (che implicitamente ha molta cache, molta memoria e banda di I/O a disposizione rispetto ad un sistema embedded di fascia "bassa").
Ma non cambia il fatto che la cache codice, e in generale la gerarchia della memoria, siano soggette a una maggior pressione, e questo incide comunque sulle prestazioni.
Se si esegue codice per una tipica applicazione "pesante" generato da un compilatore decente, il codice A64 è già sufficientemente compatto di suo anche rispetto ad x86-64.
No. Ecco qui (http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf) uno studio sulla densità del codice, che di recente è stato aggiornato qui (http://web.eece.maine.edu/~vweaver/papers/iccd09/ll_document.pdf) con ARM64: come vedi ARM64 rimane meno denso di x86-64, sebbene non ci sia molta differenza.
Il decoder dei Cortex A57 lancia in esecuzione 3 istruzioni per ciclo con fino a 128 micro-op in fase di esecuzione e fino ad 8 micro-op in esecuzione simultanea per ciclo.

Mentre l'A72 ha il decoder sempre da 3 istruzioni per ciclo, ma che vengono espanse fino a 5 micro-op simultanee (rispetto ad A57 hanno strutturato in modo diverso le unita di esecuzione ed aumentato la granularità delle micro-op).
Nella presentazione fatta da ARM Ltd. lo confrontano più con i Core M che con gli Atom:
http://cdn.arstechnica.net/wp-content/uploads/2015/04/cortex-a72-vs-core-m-broadwell.png
Premesso che aspetto di vederlo sul campo (avevo già visto queste slide alla sua presentazione), qui parliamo già di processori OoO che decodificano ed eseguono (fino a) 3 istruzioni per ciclo di clock, e dunque siamo in una classe diversa rispetto agli Atom di cui parlavamo.
Se sia un vantaggio oppure no dipende dal tipo di codice che viene eseguito e dall'architettura "completa" che si ottiene alla fine.
Per questo alla fine più che i benchmark contano le prestazioni effettive che sia hanno nel campo di utilizzo specifico.
Senz'altro ma, rispetto a quello che dicevi prima, queste piattaforme ad alte prestazioni presentano più core rispetto ad altre basate su x64, e dunque il loro sottosistema di memoria è soggetto a una maggior pressione, impattando sulle prestazioni.

Purtroppo non sono abbastanza. Ad esempio nel caso di CPython devi estrarre l'argomento, se è presente, e non puoi farlo con quelle istruzioni. Scenari del genere si ritrovano con virtual machine ed emulatori, e quindi non sono così comuni.

Uhm! Mi sa che hanno tenuto conto anche di quello, le tipologie di istruzioni condizionali di A64 è molto più vasta di quelle su x86-64.

Certamente è un gran passo avanti rispetto ad avere soltanto CMOV e SET (che però è più comoda) di x86/x86-64.

La "MOV condizionale" su A64 in realtà non include solo le semplici MOVcc degli x86 ma anche le SETcc e molto ancora.

Anzi sono supportate le istruzioni equivalenti a set condizionali ad 1, 0 oppure a -1 in modo da coprire tutti i casi utili.

Infatti nella documentazione parlano di "conditional select" indicando tutte le varie "mov condizionali", "set condizionali", ecc.

Uhm! Mi sa che hanno tenuto conto anche di quello, le tipologie di istruzioni condizionali di A64 è molto più vasta di quelle su x86-64.
Ma non mi pare di ricordare che includa anche quelle aritmetiche/logiche (AND per il masking) e di shift (per selezionare il giusto gruppo bit), o in generale operazioni sui bitfield (che mi pare non abbia). EDIT: vedi sotto.

Queste sono necessarie per estrarre le informazioni che servono dai byte dell'opcode che sono stati letti, per poi prendere decisioni sul da farsi.
La "MOV condizionale" su A64 in realtà non include solo le semplici MOVcc degli x86 ma anche le SETcc e molto ancora.

Anzi sono supportate le istruzioni equivalenti a set condizionali ad 1, 0 oppure a -1 in modo da coprire tutti i casi utili.

Infatti nella documentazione parlano di "conditional select" indicando tutte le varie "mov condizionali", "set condizionali", ecc.
Nel frattempo ho recuperato il documento di presentazione dell'architettura. Ecco qui:
The conditional instruction types are:
• Conditional branch: the traditional ARM conditional branch, together with compare and branch if register
zero/non-zero, and test single bit in register and branch if zero/non-zero – all with increased displacement.
• Add/subtract with carry: the traditional ARM instructions, for multi-precision arithmetic, checksums, etc.
• Conditional select with increment, negate or invert: conditionally select between one source register and a
second incremented/negated/inverted/unmodified source register. Benchmarking reveals these to be the
highest frequency uses of single conditional instructions, e.g. for counting, absolute value, etc. These
instructions also implement:
o Conditional select (move): sets the destination to one of two source registers, selected by the
condition flags. Short conditional sequences can be replaced by unconditional instructions
followed by a conditional select.
o Conditional set: conditionally select between 0 and 1 or -1, for example to materialize the
condition flags as a Boolean value or mask in a general register.
• Conditional compare: sets the condition flags to the result of a comparison if the original condition was
true, else to an immediate value. Permits the flattening of nested conditional expressions without using
conditional branches or performing Boolean arithmetic within general registers.
Dunque sì: ha la conditional set, esattamente come la SET di x86/x64.

Ma il set di istruzioni condizionali è ovviamente limitato a selezionare valori.

Ma non mi pare di ricordare che includa anche quelle aritmetiche/logiche (AND per il masking) e di shift (per selezionare il giusto gruppo bit), o in generale operazioni sui bitfield (che mi pare non abbia).

BFI, BFM, BFXIL per i gruppi di bit

Inoltre molte delle cose fattibili con istruzioni condizionali si possono fare
eseguendo in interleave su due gruppi di registri disgiunti le due alternative
e poi con una CSEL selezionare il risultato tra due sequenze alternative.

BFI, BFM, BFXIL per i gruppi di bit
OK. Mi sa che devo dare una ripassata all'ISA ARM, perché col tempo sto dimenticando informazioni importanti come questa.
Inoltre molte delle cose fattibili con istruzioni condizionali si possono fare
eseguendo in interleave su due gruppi di registri disgiunti le due alternative
e poi con una CSEL selezionare il risultato tra due sequenze alternative.
Certo, puoi organizzare il codice in modo da emulare il funzionamento di quello che manca, ma devi ricorrere a più istruzioni per preparare i dati e infine selezionare quelli che ti servono.

Certo, puoi organizzare il codice in modo da emulare il funzionamento di quello che manca, ma devi ricorrere a più istruzioni per preparare i dati e infine selezionare quelli che ti servono.

Nella maggior parte dei casi (su sequenze relativamente brevi) è come avere tutte le istruzioni condizionali, c'e' solo un istruzione in più alla fine per selezionare il risultato.

"Preparare i dati" non è un problema, semmai servono più registri per i valori temporanei (nel caso peggiore due o più sequenze di istruzioni interleaved e senza interdipendenze che scrivono su registri differenti per valori temporanei e risultati).

E' probabilmente anche per questo che con A64 i registri interi sono stati aumentati di numero.

Concordo. Ma anche quelli dell'FPU sono raddoppiati; solo che in questo caso viene fatto più che altro per il loop-unrolling.

D'altra parte parliamo di RISC, che col loro paradigma load/store devono necessariamente ricorrere a più registri per operazioni temporanee et similia, non potendo le altre istruzioni indirizzare direttamente la memoria, o essere comunque limitate nel caricamento di costanti.