Per il 2020 il 20% dei server sarà basato su architetture ARM

Veramente nel 1983 Intel rilasciò altri due chip di supporto per iAPX32 che permettevano si arrivare a configurazioni con fino a 63 cpu.
Non avevano mollato nel 1981, il problema fu che non trovarono clienti interessati.



L'Intel 80960 era nato da una precedente joint venture tra Intel e Siemens (BiiN)
in cui confluirono progettisti e parte di quanto già sviluppato per iAPX 432.
Da quel che restava di BiiN fu sviluppato l' 80960 ma anche se lo proposero a Steve Jobs per la workstation NeXT alla fine fu utilizzato principalmente nel settore embedded.
Il "vero" successore di iAPX 432 fu l' 80860 (sviluppato da un altro gruppo ed in concorrenza interna ad Intel con 80960).



Intel dipendeva dalla cash cow x86 già allora, ed era da quello che voleva sganciarsi
entrando in nuovi mercati, possibilmente con cpu che non potessero essere "copiate"
dai concorrenti (IBM quando scelse l'8088 per il primo PC IBM impose nel contratto che Intel non fosse l'unico fornitore, con conseguenze rilascio di licenze ad AMD, Harris ed IBM stessa, se ricordo bene).



Se "ne accorsero" quando si resero conto che stavano perdendo sempre più mercato mercato in favore di pc desktop di fascia alta.



Molti, non tutti e nel frattempo i sistemi basati su x86 erano andati più avanti e costavano molto meno.



La cosa da ricordare è che per prima cosa AMD con gli Athlon scavalcò Intel sul lato delle prestazioni, non avebbe convinto nessuno se avesse solo proposto una versione a 64bit di x86 senza prima dimostrare che poteva pure proporre prestazioni superiori.
E' stata la combinazione prestazioni+64bit, non i soli 64bit.



Era progettato per server e workstation con primo obiettivo le prestazioni, come secondo obiettivo le prestazioni e come terzo obiettivo ... non richiedere più di una centrale nucleare nelle vicinanze per alimentarlo.



Il Cortex-A72 è pensato per consumi massimi bassissimi rispetto a quelli ritenuti "nella media" per gli Alpha.



Se ricordo bene, se lo sviluppo non fosse stato bloccato, i progettisti di Alpha avevano già una roadmap mica male.

Con Alpha 21464 si parlava di core simultaneous multithreading capaci di eseguire 4 thread per core con le unita di esecuzione dimensionate per 8 istruzioni per ciclo
(con come le prime implementazioni SMT dei Pentium 4 in cui al massimo si riempivano le "bolle" nelle pipeline rispetto alla versione single-thread).

Poi era prevista l'estensione Tarantula per il vector processing che consisteva
in 32 registri da 64x128bit per registro (ognuno di essi un vettore da 64 elementi ampi 128bit, ovvero un singolo registro corrispondeva ad 8Kbit ovvero 1KByte !!!).

Il vantaggio di Tarantula rispetto alle estensioni SIMD tipo SSE/SSE2/ecc.
consisteva nel fatto che non era pensato per "ridar fiato al vecchio set d'istruzioni"
come con gli x86
ma per dare una spinta massiccia alle prestazioni oltre il punto in cui
in calcoli vettoriali conveniva usare un vector processor SIMD "massiccio".

Per rendere l'idea, le AVX-512 di Intel supportano 32 registri vettoriali da 512bit
( 'na mezza pippa rispetto ai registri vettoriali di Tarantula da 8Kbit, ovvero 16 volte più grandi).

In altre parole già 15 anni fa per gli Alpha si pensava di implementare roba che se proposta adesso annichilirebbe le cpu di punta di Intel.



Non a caso sino al 1990 ARM era solo "la cpu dell' Acorn Archimedes" di proprietà di Acorn Computers Ltd. (diventata nel 1985 una controllata di Olivetti).

E' solo con la nascita della spin-off Advanced RISC Machines Ltd. nel 1990 che ARM si apre davvero a nuovi clienti ed utilizzi (e sin da subito principalmente sistemi embedded).


Quello è uno dei fattori che hanno contribuito al suo successo, ma senza una buona architettura di base non sarebbe bastato.


Ma che devono operare con i budget energetici molto limitati degli smartphone e dei tablet.

Non ne sono sicuro, perché in passato Intel aveva progettato diversi processori senza il denaro proveniente da 8086 (che ha ingranato soltanto qualche anno dopo l'introduzione dei PC). Ne sono la dimostrazione i già citati iAPX 432 e l'80960: dove avrebbe preso i soldi per progettarli?

E' vero che poi (dopo i PC, appunto) quello dei processori è diventato il suo core business, ma Intel ha lavorato a tutto tondo nel mondo dei semiconduttori. Basti ricordare che le EPROM e le DRAM sono proprio invenzioni sue.

Beh, nel 2003, quando sono stata introdotta x86-64, Intel aveva già tirato fuori i Pentium-M, che avevano prestazioni allineate o anche superiori ai desktop di allora (P4 e Athlon-XP).

Vero, ma volevo sottolineare come già all'epoca quella di Alpha fosse un'architettura molto tirata.

Questa versione sarebbe stata, però, orientata al carico di lavoro (come il Niagara di Sun o il POWER7 di IBM) piuttosto che alle elevate prestazioni su singolo core/thread.

Non so. Il fatto che avesse registri da 8Kbit mi lascia perplesso. Tempo fa tu stesso hai parlato delle problematiche di clock skew puntando il dito proprio sui 512-bit di AVX-512.

Ad esempio in quest'articolo si parla del fatto che EV9 (suppongo sarebbe stato quello il successore di EV8) con Tarantula sarebbe stato in grado di eseguire fino a 32 operaioni a doppia precisione per ciclo di clock. 32x64 = 2048 bit. Mi sembrano tantini.

Poi ci sarebbe da vedere in che modo quei 32 set di 64x128bit registri sarebbero stati effettivamente utilizzati (mi riferisco al modo in cui le istruzioni svolgevano le operazioni).

Altra cosa abnorme è l'uso di ben 16MB di cache L2. All'epoca! Roba che oggi si deve soltanto per la ben più lenta L3.

Per cui sono abbastanza dubbioso sull'effettiva fattibilità e capacità di calcolo di questa particolare unità SIMD. Comunque in giro c'è poca roba, purtroppo; ho scaricato qualche slide e me la studio quando avrò un po' di tempo.

Di buone architetture RISC all'epoca ce n'erano già diverse. Il vantaggio di ARM era dovuto al fatto che era piccola, e tutto sommato aveva delle discrete prestazioni (anche se non paragonabili ai mostri sacri dell'epoca: MIPS, PowerPC, e poi il già citato Alpha).

Guardando oggi ARMv8, che è sostanzialmente una nuova architettura, si può vedere come tanti capisaldi dell'ISA a 32 bit siano stati tolti di mezzi, e che questa nuova ISA sia estremamente simile a quella di Alpha e MIPS. A motivo che adesso ARM ha puntato tutto sulle prestazioni.

Verissimo, ma ciò non toglie che siano micro-architetture estremamente tirate e complesse. Eseguire tutte quelle istruzioni per ciclo di clock, e OoO (non per Denver, che però si basa su altro), è un risultato notevole, e molto difficilmente vedremo delle rivoluzioni. Ovviamente mi focalizzo sempre sulle prestazioni su singolo core/thread.

Si, ma le geometrie ottimali cambiano con il fattore di scala, come pure il fatto che
quell'unita sarebbe stata separata dai core superscalari+multithreading ed interconnessa in modo differente alle cache.

Il vbox (il core vettoriale) di Tarantula si interfacciava [U]direttamente[/U] con la L2, di fatto i suoi 32 registri da 1KB erano più simili ad una cache L1 da 32KB come velocità di accesso
(più lento ma con un parallelismo a dir poco massiccio nell' esecuzione).


Quindi da un lato i core superscalari multithreading ("le auto da corsa" per il number crunching "ad alta velocita" , con percorsi di esecuzione complicati tipo loop e molti branch ecc. tipo delle auto da corsa, mentre dall'altro c'e' il vbox di Tarantula ("il treno merci" che esegue codice tipicamente vettoriale, più "prevedibile" con predicazione delle istruzioni e con parallelismo massiccio, per "macinare" al meglio grosse quantità di dati, roba enorme che arriva a saturare la banda di I/O a livello della cache L2 (per questo si interfacciava li).



Considera che con una singola istruzione tra due dei suoi registri, il vbox
poteva inviare in esecuzione fino a 64 istruzioni scalari a 128bit.
Tenere alimentate 32 unita non sarebbe stato un problema, sarebbero state esse il collo di bottiglia.



Sarebbero stati utilizzati esclusivamente su roba vettoriale "grossa" che sarebbe stata eseguita più agevolmente ed in modo più efficiente dal vbox (più lento rispetto ai core ma con banda di I/O più ampia)



La cache L2 era partizionata in 16 banchi, probabilmente le prime implementazioni sarebbero stare degli MCM (Multi Chip module) con più "chip L2" dedicati.

Qui tutto l'ambaradan viene spiegato in modo sintetico ma con sufficienti dettagli:
www.ee.duke.edu/~sorin/prior-courses/ece259-spring2006/presentations/tarantula-harting.ppt
www.ee.duke.edu/~sorin/prior-courses/ece259-spring2004/presentations/tarantula-meixner.ppt

In pratica Tarantula era un core VLIW "lento" abbinato ai core EV8 "veloci" con ognuna delle due parti ottimizzata per un tipo specifico di carico computazionale.

Finalmente ho avuto modo di leggermi le presentazioni di Tarantula.

In parte ricorda il design di Xeon Phi, dove l'unità scalare è separata da quella vettoriale, anche se condividono entrambe le cache.

Non poteva essere altrimenti, perché la cache L1 era troppo piccola per poter soddisfare la fame di bandwidth di VBox.

Ricorda molto Xeon Phi, come già detto prima. C'è anche la predicazione anziché l'esecuzione condizionale,anche se Xeon Phi ha ANCHE il supporto all'esecuzione condizionale di certe istruzioni, perché ci sono scenari, anche vettoriali, in cui ciò risulta necessario (le avevo previste indipendentemente anche nella mia ISA, ma poi ho scoperto che Intel le aveva introdotte con Knights Corner, se non ricordo male, perché prima non c'erano).

Per essere precisi, Xeon Phi è ben più giovane come ISA SIMD, quindi non è Tarantula che ha copiato alcuni concetti da Xeon Phi, ma è presumibile il viceversa.

Mi pare di aver letto che è possibile lavorare su 16 lane (ogni lane che lavora su una quadword = 64-bit), e su ogni lane applicare due operazioni. Per ciclo di clock, ovviamente. 64 istruzioni scalari a 128-bit per ciclo di clock si discostano dalle 16 * 2 operazioni per cicli di clock.

In ogni caso 64 * 128-bit è un valore che di per sé è enormemente più elevato, e che per forza di cose crea problemi di clock skew. Non è chiaro in che modo abbiano potuto aggirarlo. Magari all'epoca l'effetto non era sentito, ma alle frequenze + processi produttivi attuali lo sarebbe sicuramente, dunque VBox avrebbe dovuto lavorare a basse frequenze per evitare questi problemi.

Vengono utilizzate soltanto delle "slice" alla volta. Si prendono 16 valori (lane) da ognuno di questi registri, e si lavora solo su quelli.

Considerato che XBox ha comunque 32 registri vettoriali, IMO rimane un'esagerazione avere registri vettoriali così grandi.

Per cui il design sarebbe stato ancora più complesso.

A parte questo, sarebbe rimasto l'enorme collo di bottiglia della banda verso la memoria, che non poteva essere espansa a piacimento. Alla fine, sì, lavori sui vettori internamente, ma poi quei dati li devi pur leggere e poi scrivere.

Ho letto tutto, grazie. Purtroppo rimango scettico a causa delle scelte di cui sopra. Inoltre anche i benchmark presentati mi sembrano eccessivamente ottimistici. Poi certe cose mi suonano strane: codice EV8 ottimizzato per EV6, mentre VBox è stato scritto tutto in assembly.

Ci sono, insomma, tante cose che mi lasciano pensare che quest'esperimento nella vita reale non avrebbe potuto rendere per com'è stato presentato. Ma rimane una mia opinione basata su quel poco che ho letto, sia chiaro.

Interessantissima discussione tua e di cdimauro che mi fa tornare alla memoria le Workstation che ogni tanto vedevo in passato, DEC, Silicon Graphics, SUN.
Allora si rimaneva a bocca aperta vederle in azione, non c'era nulla di paragonabile in ambiente PC, anche se i costi di queste macchine erano esorbitanti.

Mi chiedo perché le architetture RISC di allora, che effettivamente avevano un potenziale enorme, non abbiano avuto un seguito e mettersi in competizione anche oggi, a parte ARM.
Nello specifico, visto che si parla di ALPHA, (CPU che montavano i super computer Cray), negli anni a cui si fa riferimento l'ambiente naturale era UNIX, poi supportato anche dal neonato Linux da cui deriva e da Windows NT, eppure non sono riuscite a ritagliarsi uno spazio, oggi anche le Workstation montano processori Intel Xeon che è un x86, ma in particolare non hanno trovato spazio nell'allora fenomeno di massa che si chiamava PC.

Non hanno capito il mercato oppure la discriminante fu la compatibilità x86? ..quello che nel tempo si è chiamata Wintel

Se non ti dispiace, ti riporto la mia opinione. LMCH potrà fornirti la sua quando avrà tempo e/o voglia.

A mio avviso quella è soltanto una delle componenti, ma che è subentrata soltanto dopo parecchio tempo, quando cioé il parco software x86 è diventato smisurato.

Un altro fattore è rappresentato dal miglior rapporto prestazioni / prezzi delle soluzioni x86, dovuto all'abbattimento dei costi di questi processori, grazie alla grandissima diffusione.

Infine, va tenuto conto un altro importante fattore, che è comunque base del precedente: le prestazioni. Grazie agli investimenti e, soprattutto, alla ricerca, gli x86 hanno saputo raggiungere e perfino superare le prestazioni dei processori RISC più blasonati.
Il paradigma / macro-famiglia RISC aveva senso quando i transistor impacchettati in un chip erano pochi, ma quando siamo arrivati già nell'ordine dei milioni (anche per i RISC) il discorso è completamente cambiato. Oggi che abbiamo dalle diverse centinaia fino a diversi miliardi di transistor in un chip può immaginare quanto ormai i vantaggi dei RISC siano del tutto trascurabili.

Grazie della risposta che condivido.

L'unica parte che mi pone delle domande è quella in grassetto, nel senso che è vero che Intel ha investito molto nell'evoluzione di x86 e l'ha portata a ciò che è oggi, CPU dal prezzo relativamente competitivo con ottime performance in relazione ai consumi, ed è vero che l'architettura RISC aveva dalla sua le ottime performance quando il numero di transistor su singolo chip erano minori, ma come sarebbe stata l'evoluzione dell'architettura RISC al giorno d'oggi se avessero investito come Intel?

Domanda che credo non troverà mai risposta..

In realtà Intel, e in generale i produttori di processori x86, ha preso a piene mani dalle tante tecnologie che sono state sviluppate in precedenza proprio dai produttori di processori RISC. Tanto che, alla fine, un processore x86 da quasi una ventina d'anni a questa parte ha all'interno una sorta di core RISC che si occupa dell'effettiva esecuzione delle (micro)istruzioni (uop).

La ricerca delle prestazioni per x86 ha coinvolto principalmente il decoder, e in maniera secondaria il cranking delle istruzioni (in uop) e la loro esecuzione. Tutte cose difficilmente sono utilizzabili dai RISC, che NORMALMENTE non hanno di questi problemi (PowerPC e ARM/ISA a 32-bit, invece, sì, perché hanno istruzioni parecchio complesse).

Non so quanto abbiano inciso gli investimenti, perché a mio avviso tutto ciò rientra a pieno titolo nella sfera dell'inventiva degli ingegneri. Le idee o le hai oppure no, a prescindere da quanti soldi hai nel portafogli. Infatti anche aziende piccole hanno avuto idee interessanti su come accelerare le prestazioni dei processori x86. Ricordiamo NexGen (poi acquisita da AMD) e Transmeta.

Alcune idee innovative di Intel, però, si stanno riversando anche su altri processori. In particolare, ARM ha presentato di recente l'A72, che ha introdotto una sorta di micro-op fusion (fusione di 2 uop in una sola; quindi si possono eseguire 2 uop al "costo" di una sola), che migliora un po' le prestazioni.

In futuro magari potremmo vedere qualcosa come il Loop Stream Detection, che consente di spegnere completamente il decoder mediamente per l'80% del tempo, anche se su un RISC ha relativamente poca importanza (i decoder sono molto più semplici).