Cesoia ha scritto:Con ARM-64 hai un datapath esteso,unita' di calcolo obbligatorie quali NEON e VFP,ABI unificato,ISA a 64 bit complementare,semplificata e separata (rispetto al 32). La retrocompatibilita' con i 32 bit risulta esserci ma solo con solo con la revisione AArch32 del set.
La situazione e' abbastanza differente rispetto al metro di paragone x86 a 32 e 64 bit dove quest'ultima risulta essere una semplice estensione della prima.
http://www.realworldtech.com/arm64/2/
Sostanzialmente,in ARM hanno semplificato,ridotto e corretto anziche' limitarsi ad aggiungere.
Con ARM-64 potevano cancellare tutto e volendo non mettere nemmeno la compatibilità a 32-bit, visto il mercato che ha ARM se lo potrebbe permettere (è tutto o quasi mercato embedded), x86 non se lo poteva permettere e AMD l'ha capito (cosa che Intel non capiva con IA-64 che alla fine non l'ha voluto nessuno, HP si è pentita enormemente nel non avere adottato solo AMD64 o SPARC64 nei suoi server), e ci ha ficcato dentro la legacy mode. Anche x64 ha il supporto SSE2 obbligatorio (potevano fare anche le SSE3 obbligatorie, ma AMD non ha colto l'occcasione e i primi Athlon 64 arrivavano solo alle SSE2). Il supporto ad IA-32 è stata una delle funzioni fondamentali per far vincere AMD64 rispetto ad IA-64 (che poi non è mai stata gran cosa, se non per il mercato marcheting di NVIDIA.
Cesoia ha scritto:ARM NEON non e' altro che l'unita' SIMD del RISC ARM alla pari di VIS per SPARC,Altivec per PowerPC,ecc.
Comunque concordo con te che e' imparagonabile alle diverse estensioni x86.NEON mantiene la sua specificita' operativa. Storicamente i RISC sono stati dotati di FPU molto potenti e ben progettate sia a livello di silicio sia a livello di ISA. Cosa che ovviamente non ha mai avuto l'x87 di Intel. Le varie estensioni x86 vanno quindi ad affiancare ma molto piu' spesso a sostituire le x87 che sono state da sempre il tallone d'achille dell'architettura.
Tutte le estensioni SIMD per x86 sono RISC-like, ISA compresa (sarebbe stato un merdaio fare il contrario in questo caso). L'FPU di intel voleva competere con le FPU ad alta precisione, senza però andare fino a 128-bit. Sì, sicuramente è stata una minchiata assurda, all'epoca bastava una FPU a 64-bit (anzi, basta tutt'ora). Pessimo tentativo di strizzare l'occhio al mercato professionale ad alta precisione, non c'è da dire altro (ah sì, un certo bug che costò giustamente miliardi di dollari ad Intel).
Cesoia ha scritto:ARM 64 dovrebbe costringere i produttori a standarizzare il percorso evolutivo dell'architettura. Per quanto riguarda GCC,purtroppo,fa' pieta' su tutte le architetture e non da ieri. Non c'e' architettura che abbia un supporto soddisfacente.Ho avuto esperienze negative sia con SPARC sia con Alpha sulla quale compilava addirittura codice errato. Di certo Alpha non ha mai sofferto dei problemi delle architetture custom di ARM. Non credo quindi che GCC su ARM faccia pieta' per quel motivo li'.Semmai e' un motivo ulteriore per peggiorare la situazione del compilatore.
Ho la netta sensazione che molti progetti opensource si limitino a “fare” il lavoro anziche' preoccuparsi di farlo bene.
Il problema è che non solo GCC fa pietà per ARM ma pure clang. Alpha è durato poco in fin dei conti, SPARC ha il suo toolset del produttore (architettura che si evolve per far vivere Java nei server). Sia GCC sia Clang invece danno ottimi risultati in x86, paragonabile a MSVC e a ICC.
Se ARM holding intende mettere dei seri paletti per le personalizzazioni (a volte storpiature) di ARM allora è meglio che si metta in testa che potrebbe perdere clienti... Ma dubito che una holding finanziaria farà così..
Cesoia ha scritto:Difatti e' quello che avevo scritto: nucleo RISC + traduttori).Precisamente dall'archiettura 686.
Il 80486 è stato il primo ad avere una pipeline RISC-like. L'nx586 (1994 - stesso tempo del pentium) di NexGen (acquistata due anni dopo da AMD) aveva invece già il traduttore, copiato in seguito da Intel ed AMD (non solo per la complessità ma anche per continuare ad evolvere MMX e le successive SSE).
Cesoia ha scritto:Su questo ci sarebbe da discutere. Il design RISC impone dei vincoli realizzativi stringenti e semplificati rendendo l'ISA ed il silicio sottostante intimamente legati fra loro. E' sempre stato cosi'.Sicuramente internamente le CPU x86 lo sono. Tuttavia anteporre un livello di traduzione fra l'ISA x86 e ed il nucleo RISC (slegando completamente il set “visibile” dal silicio) come avviene nei moderni x86 e' una bestialita' senza pari. Probabilmente queste scelte sono il frutto di un compromesso che ha permesso ad intel di crescere enormemente in questi vent'anni ma fermiamoci a questo. L'architettura e' andata molto bene quando si trattava di “crescere” ed “aggiungere” mentre i problemi sono sorti nel momento in cui era necessario ridurre e mantenere un buon compromesso energetico. Il nodo realizzativo di certo aiuta ma ad oggi,di variazioni importanti sull'architettura non se ne sono visti.
Il traduttore dell'ISA non ha impatto prestazionale (qualche pico-secondo? probabilmente meno), il grosso dell'ISA x86 è costituito da estensioni SIMD a superset (MMX->SSE...SSE4.5 -> AVX...AVX-512) e da singole estensioni di sicurezza (che sgravano il software di non poco.. non conosco tuttavia la situazione relativa in ARM) o per il multithreading.
L'ISA tocca solo chi implementa i compilatori oggigiorno ed è un bene che sia così dato che certe ottimizzazioni non puoi farle a mano, nemmeno se scrivi un codice assembly perfetto. Esempio semplice: caching dei registri in base alle ottimizzazioni globali del programma, forzare del codice macchina tramite assembly rischia di rompere tale meccanismo e di peggiorare la situazione, tant'è che è consigliato solo studiarlo per capire come cazzo funziona la macchina che usi e usarlo solo per i casi non trattati correttamente dal compilatore).
Le ISA RISC sono semplicissime da imparare, dopo poco tempo puoi fare quasi a meno della carta delle istruzioni o quasi e ARM ha appunto un'ISA abbastanza semplice, tanti registri e poche funzioni ad hoc (rispetto ad x86 nel suo insieme) e il risultato? Il risultato è che non ci si affida al microcodice della macchina chiamando determinate funzioni ed estensioni ma bisogna scriversi tutto da sé ed il microcodice si deve pappare quello. Le prestazioni ne risentono.
Cesoia ha scritto:Vero. Difatti tutti i sistemi CISC hanno trovato degna sepoltura fra la fine degli anni '80 e la meta' degli anni '90.Non cosi' e' stato per x86 dove Intel ha trovato il modo di ancorarsi ad una soluzione che non ha piu' senso da troppo tempo.
Il problema del mercato e della retro-compatibilità per intel c'era già negli anni '80 ed eccoti nata IA-32. Se non lo avesse fatto probabilmente sarebbe uscita fuori. A quel tempo un'emulazione software delle istruzioni a 16-bit era impensabile. Se ci pensi fecero l'unica scelta logica per rimanere vivi. ARM era appena nata, pertanto non ho la più pallida idea di quale architettura ci saremmo trovati al suo posto.. e forse non voglio nemmeno immaginarlo, probabilmente sarebbe morta pure quella poco dopo. Ogni volta che un'architettura muore o rompe la retro-compatibilità sono una quantità di denaro perso considerevole, gli unici a permetterselo sono le console, e in più generale i sistemi embedded.
Cesoia ha scritto:L'x86 e' un insieme di aggiunte successive senza una visione globale di quello che si andava ad implementare. E' come far lavorare diversi team di sviluppo senza un capoprogetto. Non vorrei esserci!
il P4 ha avuto molto in comune con Itanium (a livello di pipeline) e forse la sua inefficienza nasceva proprio da quello.IA64 era fantastico sulla carta,ma demandare la complessita' al compilatore si e' rivelato piu' difficile di quanto si pensasse.
Come detto sopra,aggiungere un livello di complessita' fra ISA x86 e nucleo RISC senza avere il coraggio di tirare una riga e ricominciare da capo (Intel come capofila poteva e doveva farlo) e' stata la peggior dimostrazione di quello che e' Intel.
L'insieme sarà pure orrendo da vedere, ma devono maneggiarlo solo chi implementa i compilatori (e non mi pare che i compilatori x86 facciano schifo anzi, sono forse i migliori in circolazione), ergo fine della storia. Al giorno d'oggi l'assembly è bene studiarlo ed è bene conoscere almeno un po' di quello della macchina con cui lavori, ma utilizzarlo è quasi sempre stupidità. Quelle che chiami aggiuntive senza una visione globale sono l'unica soluzione per non mandare tutto a bagasce anche se a quanto pare a questo mondo in molti (che spesso non hanno idea di cosa parlano) vorrebbero trovarsi il software utilizzato fino al giorno prima non più funzionante solo perché Intel è brutta e cattiva (cosa probabilmente vera così come è stato un certo CDA di una certa AMD che ha rischiato la bancarotta a causa di una certa acquisizione di una certa ATI...)
E no, non parliamo di emulazione: IA-64 non era sto granché come architettura di base a livello di performance (in quel periodo le performance erano tutto, anche più dei consumi per i server) e l'emulazione hardware che offriva di IA-32 faceva pietà, tanté che Microsoft decise (ed impose) un'emulazione software di IA-32 sui sistemi Windows che supportavano IA-64 (e i risultati furono pure migliori).
Emulare x86-IA32 con performance decenti era impensabile, lo è quasi tutt'ora, rincominciare tutto solo per avere qualche registro in più e un'ISA più semplice e buttando via tutte le estensioni che già aveva e che schifo non facevano era semplicemente fuori dalla portata di Intel, come ha dimostrato con IA-64. Lo era per tutti e lo è ancora.
Se c'è qualcosa da fare con x86 ora è smettere di produrre software a 32-bit, smettere di usare l'IA-32 nello scrivere nuovo codice, fine. E dire: ohmmioddio x64 porta solo a più RAM! Ommioddio mi dura meno la batteria perché usa più registri e i puntatori (che non sanno nemmeno cosa sono) sono lunghi il doppio è la coppia di stronzate colossali che si continua a leggere in giro spesso in quei luoghi dove si vuole distruggere tutto a prescindere appunto senza sapere di cosa si parla - questo non è uno di quelli fortunatamente (fine sfottò mirato a certi portali di gossip che si spacciano di informatica).
Cesoia ha scritto:I RISC sono tutti registro-registro. Che poi sia implementata anche altrove,questo,non lo escludo.
Una più teorica definizione di RISC dovrebbe comprendere solo il modello load-store e non il register-register move (almeno credo, ma potrei sbagliare). Ma poco importa, alcune architetture RISC di oggi sono molto meno rigide che in passato (ARM sicuramente è meno rigida di MIPS in questo senso).
OpenRISC e RISC-V (entrambe RISC) sono basata puramente sul modello load-store, SuperH (RISC) supporta entrambi (register-register e register-memory)
Alcune ISA CISC permettevano il register-register (e Z/ pure il memory-memory xD).
Sarebbe interessante guardare poi le varie architetture delle GPU, ma il grosso è segregato .-.
Cesoia ha scritto:Errato. ARM e' stato concepito e sviluppato per le alte prestazioni. Archimedes ne era la dimostrazione. Pipeline cortissima e logica cablata. I tecnici,mutuando le ricerche del Berkley RISC II hanno preferito semplificarlo evitando l'implementazione del register window cosa avvenuta sullo SPARC. A posteriori la scelta si e' rivelata vicente.
L'adeguamento al mercato embedded avvenuto solo in fasi successive ha modificato pesantemente lo sviluppo (standarizzato e coerente) dell'architettura.
Allora qui dobbiamo metterci d'accordo su cosa significa "alte prestazioni". Anche MIPS è stato ficcato dentro alle console, eppure né ARM né MIPS si sono mai inseriti veramente nel settore "alte prestazioni", tant'è che appunto hanno spopolato in mercati differenti.
Cesoia ha scritto:Stai descrivendo una delle motivazioni che portarono a precise scelte progettuali che portarono alla realizzazione dell'architettura RISC di Stanford nei primi anni '80 da parte del Prof. Hennessy. Proprio perche' l'inefficienza e la limitazione dell'approccio registo-memoria dei CISC presenti allora,come x86,erano intollerabili. Oggi x86 e' spinto da hw sottostante completamente differente. Magari le prestazioni non sono esattamente dovute al set d'istruzioni x86,giusto? Poi,scusa,me lo confronti con un'architettura embedded? Attendiamo almeno di avere qualcosa di piu' confrontabile,magari da AMD, e poi vediamo.
Negli anni '80 il gap fra memorie e CPU era ancora tollerabile, non lo fu più negli anni '90. Intel fece la scelta sbagliata nel creare Ia-32 e ARM quella giusta pur non avendo fonderie ed essendo appena nata? Queso non ne ho idea, è probabile, ma quando nacque x86 l'approccio register-memory polverizzava i register-register nel loro complesso. Per il resto si ritorna al discorso di cosa avrebbe permesso di campare ed emergere ai vari attori.
Ancora di più oggi l'architettura della memoria primoria è una specie di cancro per l'informatica; altro che di SSD il settore e configurazioni multi-GPU che richiedono un contratto industriale da parte dell'Enel, si ha necessità di una vera e propria rivoluzione che spazzi via il DMA, la RAM e tutto quello che ci ruota attorno, perché se un algoritmo di complessità O(N) risulta preferibile di diverse magnitudo in tempi di esecuzione ad una O(log n) o addirittura ad una O(1) allora qualcosa non va.
Con cosa dovrei confrontarla poi, con quello che non c'è o coi rebrand di Seamicro in AMD?
Cesoia ha scritto:X86 e' nata come architettura general purpose limitata ed a bassissimo costo. Le sue caratteristiche rispecchiano il periodo: meta' anni '70. Le prestazioni fino a meta' degli anni '90 con l'arrivo dell'i686 non erano nemmeno paragonabili ai sistemi RISC utilizzati in qualunque ambito lavorativo e professionale. La fortuna di questa architettura e' agganciata alla diffusione dovuta al successo del PC IBM,Microsoft Windows come standard ed il costo relativamente basso. Solo in seguito sono arrivate le prestazioni che hanno ribaltato definitivamente la situazione:un po' quello che rischia di fare ARM oggi,nei confronti del monopolista x86.
Non hai capito quel che volevo dire: il register-memory rispecchierebbe pienamente la natura vera dei calcolatori (in un mondo ideale dove non esiste il gap fra memoria primaria e CPU che abbiamo oggi) e lo sfottò è per quegli benemeriti imbecilli che non considerano la memoria un problema dato che per loro programmare significa applicare il concetto di funzione ad una cosa astratta ed eterea, era una divergenza sul discorso XD
Cesoia ha scritto:Vero. Ma oggi,in generale,non contano piu' solo le performance straripanti garantite da x86 se lo scotto da pagare e' l'efficienza.
Dipende dal settore, io parlo sempre in ottica di alte prestazioni dove è lì che ARM sfiderebbe x86: a me se il PC consuma 10 o 20W in meno non me ne importa una eva, sono una decina di euro all'anno in bolletta. Il mercato server ormai è orientato verso il cloud e alla nicchia dei dedicati ad alte/altissime prestazioni e alla nicchia ancor più piccola dei super-computer. ARM per ora non riesce a competere in queste nicchie, x86 ci ha messo anni a svilupparsi per esse, non è che dall'oggi al domani mi trovo un supporto alla virtualizzazione pazzesco ed una serie di estensioni SIMD che fanno dimenticare NEON, potrebbero farlo solo diventando un'architettura dove i consumi non sono più tenuti sotto controllo e comunque ci impiegherebbero un sacco di tempo.
Cesoia ha scritto:Mai detto questo e tutto sommato non ho mai sentito dire ad ARM nulla del genere. Piuttosto l'obiettivo e' dimostrare che si possono fare le stesse cose a performance paragonabili con molta meno potenza e meno dispendio di energia.
Chi notoriamente alimenta questo genere di falso confronto (potenza pura) in cui ovviamente ARM risulta perdente e' proprio il marketing di Intel,lo stesso che ci ha raccontato per vent'anni che i Gigaherz erano tutto,lo stesso che ci voleva convincere che un P4 era meglio di un Athlon64.
Lo stesso che evita di parlare accuratamente di efficienza,inventandosi termini fantasiosi come l'SDP al posto del piu' onesto TDP.
Il silicio non è metafisico, ha dei limiti per natura. Intel ci si sta scontrando da un pezzo e ci si scontreranno anche i nodi che non usa intel, in parte sta già accadendo, altrimenti i piani delle varie fonderie sarebbero tutti puntuali come un'orologio atomico.
Il marketing di intel personalmente lo detesto, fra tutto ficcherei quel dannato gingle su per il sedere al CDA, qui stiamo parlando di potenza di calcolo (visto che si parlava di sfidare x86), non certo di sfidare gli Atom (che tra l'altro perderebbero a mani basse se i telefoni e i tablet di oggi non avessero un'autonomia ridicola per via di batterie insignificanti e di schermi a risoluzioni demenziali). Se poi vogliamo trovare chi distrusse il mito dei GHz di Intel fu proprio AMD con i K7.
L'SDP ha un suo perché, difficilmente a pieno regime tutta la pipeline del processore, e AMD farebbe bene a pubblicarlo (la scusa che c'è solo il TDP per gli OEM non sta in piedi, agli OEM AMD darà ben altra documentazione). Se proprio vogliamo trovare un valore disonesto sono i valori di TDP che riportano AMD ed Intel, anzi soprattutto Intel che non corrispondono affatto a quelli riportati sul sito ark.intel.com (dove ci sono sia SDP che TDP), basta usare le stesse librerie che intel mette a disposizione per vedere sistemi a default che crashano a gogo o dissipatori stock indegni che fanno andare le CPU in protezione per via del calore che non riescono a dissipare.
Cesoia ha scritto:La verita' e' che Intel,le sue carte con quell'architettura e con quell'approccio evolutivo se l'e' giocate tutte. Ora tiene botta a costi proibitivi con i nodi avanzati. Ma fino a quando? Non bastasse questo,il peso ed il ruolo centrale della CPU cosi' come e' stata concepita fino ad oggi e' destinato ad essere superato da sistemi sempre piu' specializzati. ARM e' pronta,Intel no.
Vedremo alla fine,dalla riva del fiume,quale cadavere passera'.
La verità è che il software va per il minimo-comune-denominatore, a meno che non sia software di settore o che il compilatore cerchi di ottimizzare ove possibile. L'architettura una volta definita quella di base quella è e quella rimane, altrimenti o la estendi (come fanno Intel o AMD) o la cambi come ha fatto ARM con ARM-64. Ma cosa vuoi fare, cambiarla ogni volta che quella di base non ti va più bene? Sarebbe da stupidi, la retro-compatibilità vale di più che i watt risparmiati e quella mezzora di autonomia in più al telefono, è meglio sviluppare relative estensioni e se un software ha bisogno di determinata potenza di calcolo può andare ad attingere a quelle (che tra l'altro hanno sempre garantito dei boost prestazionali non indifferenti), tutto il resto è colpa di chi sviluppa software dato che aggiornare il compilatore ogni 2-3 non è una tragedia se scrivi del codice quantomeno mediocre o che rasenta la sufficienza.
I costi proibitivi di intel derivano dal volersi inserire da un mercato ormai fatto (quello mobile) e nel cercare di fare una magia superando quello che ARM e MIPS hanno creato in due decenni. È una cosa semplicemente stupida. O si muoveva prima di diversi anni o era meglio che ne rimanesse fuori (esempio: avrebbe potuto concentrarsi invece sul ridurre i consumi dei sistemi di connettività centrino che sono i veri killer dei notebook negli ultimi 5-6 anni, se non di più).
La riva del fiume non la passeranno entrambi o nessuno, il limite del silicio sta a ca 1nm (al di sotto non so quanto si possa fare con degli atomi aventi raggio covalente di 111pm e raggio dello spazio atomico poco più del doppio), probabilmente fenomeni micro-elettrici metteranno i freni poco dopo dopo o subito dopo il nodo a 10nm, ergo c'è poco da fare per entrambi arrivati a quel punto (non così lontano). Se si riuscirà a metter su processi produttivi con alternative al silicio allora si può scendere ancora un po' (e per favore, qualunque piega seguirà o meno la discussione, non cadiamo nel discorso che ha fatto un certo ebete - Albero Angela - dove il grafene non inquina perché il carbonio è abbondante in natura XD)
