Link alla notizia: http://www.businessmagazine.it/news/per-il-2020-il-20-dei-server-sara-basato-su-architetture-arm_56961.html

L'azienda inglese si dimostra molto ottimista sul sucesso di mercato delle proprie architetture a basso consumo anche nel settore dei server. Varie soluzioni di questo tipo sono già disponibili ma sarà solo nei prossimi anni che i microserver basati su architettura ARM conosceranno una elevata diffusione

Click sul link per visualizzare la notizia.

Per il momento le prestazioni sono davvero scarse per un uso server che non sia semplice file server.

bha, contando come Intel abbia accellerato e stia spingendo sulle soluzioni Atom, la vedo dura che raggiungano quelle %; il recente tentativo di acquisizione di Altera poi è un'altro segno di come Intel abbia intenzione di investire ancora di piu in questo settore, e si parla di 15 Miliardi di dollari aggiuntivi pronti per essere spesi...

Parliamo quindi di SoC in grado di abbinare valida potenza di calcolo a consumi molto contenuti

Allo stato attuale, a parità di prestazioni un processore basato su architettura ARM consuma meno di uno x86?

Comunque, Intel sta spingendo ancora di più in quel settore, quindi non so quanto sia realistica tale percentuale.

No in realtà non credo proprio.
Ma ormai è entrato nella credenza popolare che arm ha il vantaggio di consumare meno.

In realtà nessuno ha mai fatto test seri in questo senso. Considera che inoltre si andrebbero a confrontare ( e spessissimo si fa proprio così ) x86 con processo produttivo molto avanzato con arm con processo produttivo vecchio di 2-3 generazioni.


In realtà arm ha realmente il vantaggio di consumare meno, nel senso che è possibile realizzare soc di bassissimo consumo con conseguente bassissime prestazioni, cosa che x86 non consente.

Ed è questo il punto. Intel l'ha capito benissimo, tant'è che si sta buttando pure nel settore dei SoC custom. Altrimenti non si capirebbe il perchè dell'alleanza con Rockchip.


Il problema dei soc intel di quella fascia è che costano molto di più.

Intel paga lo scotto della complessità e pure la posizione di quasi-monopolio. Se ci fosse un'AMD molto più forte magari i prezzi Intel sarebbero molto più bassi.

No in realtà non credo proprio.
Ma ormai è entrato nella credenza popolare che arm ha il vantaggio di consumare meno.

In realtà arm ha realmente il vantaggio di consumare meno, nel senso che è possibile realizzare soc di bassissimo consumo con conseguente bassissime prestazioni, cosa che x86 non consente.
Ma nella fascia di prestazioni dove x86 e arm coesistono attualmente il rapporto prestazioni consumo è simile, anzi forse è in vantaggio x86 al momento.
Il problema dei soc intel di quella fascia è che costano molto di più.

no, in realta con ARM è teoricamente possibile consumare meno perchè è possibile progettare chip su misura che facciano bene un singolo compito per il quale è stato pensato, che è quello che stanno pensando di fare i BIG dei servizi On-Line; Per quello Intel ha provato ( e credo riprovera o comuqnue cerchera qualcos di simile ) ad acquisire interamente Altera, per poter offrire customizzazioni aggiuntive ai suoi Atom, che per quanto riesca a farli bene rimangono CPU a 360°.

Attualmente comunque credo che Intel sia tranquillamente una spanna sopra.

no, in realta con ARM è teoricamente possibile consumare meno perchè è possibile progettare chip su misura che facciano bene un singolo compito per il quale è stato pensato, che è quello che stanno pensando di fare i BIG dei servizi On-Line; Per quello Intel ha provato ( e credo riprovera o comuqnue cerchera qualcos di simile ) ad acquisire interamente Altera, per poter offrire customizzazioni aggiuntive ai suoi Atom, che per quanto riesca a farli bene rimangono CPU a 360°.

Attualmente comunque credo che Intel sia tranquillamente una spanna sopra.

Intel riesce ad avere prestazioni migliori solo ed esclusivamente perche usa uno step più avanzato, usa in genere chip con area più grande a parità di densità ed ha limite di consumo più elevato (infatti per Intel è stato un calvario calare con i consumi senza salire troppo con i costi di produzione e/o perdere prestazioni).
Quando cominceranno a venir prodotti SoC ARM ottimizzati espressamente per server e roba ad alte prestazioni per Intel saranno dolori se non riesce a stare almeno 1..2 step avanti.
In particolare è da notare come ARM ha progettato il set d'istruzioni a 64bit, non è un caso se ha parecchi punti in comune con l'architettura Alpha della DEC, è roba pensata anche per far entrare gli ARM in settori dove conta per prima cosa la potenza di calcolo.

Intel riesce ad avere prestazioni migliori solo ed esclusivamente perche usa uno step più avanzato, usa in genere chip con area più grande a parità di densità ed ha limite di consumo più elevato (infatti per Intel è stato un calvario calare con i consumi senza salire troppo con i costi di produzione e/o perdere prestazioni).
Quando cominceranno a venir prodotti SoC ARM ottimizzati espressamente per server e roba ad alte prestazioni per Intel saranno dolori se non riesce a stare almeno 1..2 step avanti.
In particolare è da notare come ARM ha progettato il set d'istruzioni a 64bit, non è un caso se ha parecchi punti in comune con l'architettura Alpha della DEC, è roba pensata anche per far entrare gli ARM in settori dove conta per prima cosa la potenza di calcolo.

Vedremo....... i dolori a Intel dovevano farli venire diversi concorrenti e abbiamo visto la fine che hanno fatto, gli step di vantaggio di Intel sul processo produttivo sono destinati a ridursi, così come le prestazioni a parità di consumi e di die del processore, alla fine non è che in Intel sono dei babbuini e nei reparti R&D dei concorrenti lavorano geni, gli ARM sono degli ottimi processori fintanto che gli si richiedono compiti specifici e possono essere anche molto performanti, però anche loro devono crescere come architettura per poter concorrere con gli X86 nel general purpose ad alte prestazioni e a quel punto non saranno certo i pochi transistor in più o meno derivanti dal portarsi dietro la X86 tax a fare la differenza.

Intel riesce ad avere prestazioni migliori solo ed esclusivamente perche usa uno step più avanzato


E dipende molto dall'architettura anche. Si può fare un esempio banalissimo, ovvero un confronto tra un'architettura superscalare e una che invece non lo è.

Di che si vuole parlare in questo caso? Certo l'architettura superscalare avrà un IPC più elevato, ma complessità ( e spessissimo consumi ) molto più elevata. Quindi come si comporta una cpu a 4 core superscalare in confronto ad una non superscalare ma con 64 core? E magari il tipico carico di lavoro è pure di quelli facilmente parallelizzabili. E oggi come oggi, anche un sistema general purpose fa girare tanti processi che possono trarre vantaggio dall'avere molti core a disposizione.

E quindi qual è migliorie? Dipende da cosa ci devi fare. I benchmark sintetici saranno carini da guardare, ma sono totalmente inutili quando si passa alla realtà.

Quando cominceranno a venir prodotti SoC ARM ottimizzati espressamente per server e roba ad alte prestazioni per Intel saranno dolori se non riesce a stare almeno 1..2 step avanti.


Contando che Intel ha gia iniziato a fare Atom con parti hardware specifiche non ci vorra molto perchè arrivi anche lei con Atom ancora piu customizzati con coprocessori specifici e programmabili per determinate necessita del cliente...

non so è, ha tentato di acqusitare con 15 Miliardi Altera... mi sembra che di soldi da investire per arrivare anche prima di ARM ne abbia.

Contando che Intel ha gia iniziato a fare Atom con parti hardware specifiche non ci vorra molto perchè arrivi anche lei con Atom ancora piu customizzati con coprocessori specifici e programmabili per determinate necessita del cliente...

non so è, ha tentato di acqusitare con 15 Miliardi Altera... mi sembra che di soldi da investire per arrivare anche prima di ARM ne abbia.

Solo che non si sta scontrando con ARM Ltd (l'azienda) ma con tutti i produttori di chip basati su ARM e le relative produzioni specializzate in nicchie e settori differenti.
In alcuni casi si tratta pure di produttori che poi usano gli stessi chip in prodotti loro (Samsung, Hauwei, ecc.).
E' uno scenario ben diverso da quelli in cui si è trovata Intel in precedenza.

E dipende molto dall'architettura anche. Si può fare un esempio banalissimo, ovvero un confronto tra un'architettura superscalare e una che invece non lo è.

Sono cose che dipendono dall'architettura dell'implementazione, non dall'architettura "ad alto livello" in se.

Esistono sia ARM che x86 non superscalari e superscalari, ma poi anche in una stessa tipologia vi sono scelte e limitazioni progettuali differenti che influiscono sul risultato finale.

Sono cose che dipendono dall'architettura dell'implementazione, non dall'architettura "ad alto livello" in se.


Beh no, l'architettura c'entra eccome. Esempio banale: un tipo crea una rete logica non minimizzata. Stessa funzionalità di una rete minimizzata, ma molti più transistor e quindi maggiori consumi. E' un esempio stupido, ma aiuta a capire il concetto.


ma poi anche in una stessa tipologia vi sono scelte e limitazioni progettuali differenti che influiscono sul risultato finale.

Ovviamente. Le scelte possibili sono talmente tante e non esistono scelte migliori in assoluto. ARM ha basato i suoi core sul concetto di SoC customizzabile, intendendo che ogni cliente voleva/poteva/doveva aggiungerci ulteriori unità, coprocessori, dsp, ecc....

x86 invece nasce per il general purpose, in un'epoca in cui pure la grafica la faceva la cpu. Oggi si sta reimponendo il paradigma che fece grande l'Amiga ( e non solo ).

Beh no, l'architettura c'entra eccome. Esempio banale: un tipo crea una rete logica non minimizzata. Stessa funzionalità di una rete minimizzata, ma molti più transistor e quindi maggiori consumi. E' un esempio stupido, ma aiuta a capire il concetto.

Ma si tratta di efficienza di specifiche implementazioni, non dell'architettura ad alto livello.
Se implementi AArch64 puoi farlo con microcodice, con singola pipeline scalare, superscalare, multithreading, ecc. implementare il renaming dei registri, dimensionare/partizionare in vario modo le cache ed i bus di connessione tra cpu, cache ed altri moduli, ecc.
E siamo ancora a livello relativamente alto, prima ancora di fare ottimizzazioni all'implementazione della rete logica (non solo minimizzandola ma valutando se vale la pena un implementazione pienamente statica o una dinamica in base alle esigenze) ed alla circuiteria di contorno (distribuzione del clock, alimentazione, massa, schermature varie, circuiti di controllo energetico, ecc.), poi in base al processo produttivo si possono ulteriormente ottimizzare le maschere fotolitografiche andando a fare ritocchi sulle linee di collegamento e sul dimensionamento dei singoli gate, ecc.

Anche con un reference design bello e pronto poi si possono fare ottimizzazioni alle maschere o decidere di usarle tali e quali e magari pure ridurre le prestazioni per non usare un processo produttivo più recente (in modo da ammortizzare più a lungo termine i mezzi di produzione di cui già si dispone).

Per questo sino ad ora non si è ancora visto cosa può fare davvero un ARM "progettato per la massima potenza di calcolo".
Pure i nuovi core A72 sono ancora pensati per dispositivi mobilie non per server.

Apple col suo A8, nVidia con Project Denver e Qualcomm col suo Krait mi sembra che abbiano tirato fuori delle microarchitetture ARM (non nVidia, ma non voglio dilungarmi adesso perché devo correre a lavoro) votate alle prestazioni. Mi riferisco a livello di singolo core/processo/thread. In particolare l'A8 è un autentico mostro, capace di decodificare ed eseguire ben 6 istruzioni OoO per ciclo di clock.

E' difficile pensare di continuare sulla stessa strada, perché gestire tutta quella roba complica notevolmente l'implementazione. In futuro mi aspetto che puntino di più su altri aspetti (aumento delle cache a tutti i livelli, TLB, branch predictor, code, etc.).

L'architettura è ANCHE importante, perché può consentire di eseguire più "lavoro utile". L'esempio degli Atom penso sia eloquente: processo produttivo molto vecchio (mi riferisco ai primi, che erano a 32nm) e architettura in-order (2 istruzioni), ma c'è voluto il Cortex-A15 con architettura e ben 3 istruzioni per metterlo in difficoltà (ma al costo di consumi di gran lunga più elevati rispetto alle precedenti micro-architetture).

Finché si tratta di roba embedded, posso capire che ARM abbia sicuramente dei vantaggi in quanto l'architettura è certamente più semplice di quella x86 (la cui "tax" è rappresentata sostanzialmente dal decoder; l'FPU x87 ha un peso molto inferiore), ma appena si comincia a pompare mettendo cache generose, TLB, predictor, ecc., il numero di transistor esplode e gli aspetti legacy diventano trascurabili.

Un esempio di ciò è la micro-architettura di Sophia, che può competere anche con le soluzioni low-end del mondo ARM. Un altro è rappresentato da Galileo.

Il vantaggio di Intel non è dunque, soltanto dovuto al miglior processo produttivo che ha a disposizione per i suoi chip.

@GTMK: il problema di quando si parla di "prestazioni" è che difficile mettere a confronto due architetture molto diverse. E' difficile persino con micro-architetture della stessa famiglia. In genere è meglio fissare dei paletti, con un bouquet di test specifici per l'ambito applicativo in cui un certo prodotto verrà utilizzato. Esempio: per la TOP 500 dei supercomputer si usa LINPACK. ;)

...

@GTMK: il problema di quando si parla di "prestazioni" è che difficile
mettere a confronto due architetture molto diverse. E' difficile persino
con micro-architetture della stessa famiglia. In genere è meglio
fissare dei paletti, con un bouquet di test specifici per l'ambito
applicativo in cui un certo prodotto verrà utilizzato. Esempio: per la
TOP 500 dei supercomputer si usa LINPACK. ;)

Lo so, per questo ho chiesto: visto che da mesi continuo a leggere "ARM ha consumi inferiori", volevo capire se fossero affermazioni, quanto meno, basate su delle fonti. :D

Solo che non si sta scontrando con ARM Ltd (l'azienda) ma con tutti i produttori di chip basati su ARM e le relative produzioni specializzate in nicchie e settori differenti.
In alcuni casi si tratta pure di produttori che poi usano gli stessi chip in prodotti loro (Samsung, Hauwei, ecc.).
E' uno scenario ben diverso da quelli in cui si è trovata Intel in precedenza.

si ma qui non si tratta nemmeno solo di chip e singoli produttori, si tratta si sistemi server completi e finiti, e attualmente intel con IBM Lenovo HP etc. etc. è di gram lunga piu avanti rispetto ai concorrenti; tantè che sono un paio di anni che si parla di ARM Server e anopra stentano a vedersi.

al dila del pp basta guardare il salto enorme fatto dalla vecchia alla nuova architettura Atom; Intel si è gia fatta fregare una volta nel mercato Mobile, nel mercato server, dove ha anche molta piu esperienza, non si fara sormontare e i tentativi di acquisizione ne sono la prova.

al dila del pp basta guardare il salto enorme fatto dalla vecchia alla nuova architettura Atom; Intel si è gia fatta fregare una volta nel mercato Mobile, nel mercato server, dove ha anche molta piu esperienza, non si fara sormontare e i tentativi di acquisizione ne sono la prova.

Intel è molto più legnosa di quanto sembri, basta pensare alle batoste che ha preso ogni volta che ha cercato di sganciarsi dagli x86 (iapx32, il RISC i860, Itanium) ed ora ha puntato in modo altrettanto ottuso sulla strategia opposta "solo x86".

Se gli ARM cominceranno a far breccia nel mercato dei server, Intel avrà difficoltà a reagire con sufficiente velocità su più fronti (perche anche li come nel settore telefonia e tablet l'attacco arriverà non coordinato su più fronti).

Lo so, per questo ho chiesto: visto che da mesi continuo a leggere "ARM ha consumi inferiori", volevo capire se fossero affermazioni, quanto meno, basate su delle fonti. :D
Idem. Alla fine ciò che succede è continuare, dopo tantissimi anni, ad associare x86 = 8086 = schifezza, senza contestualizzare né riportare fatti a supporto di queste tesi.

P.S. Scusami se ho scritto male il tuo nick, ma non sono ferrato nello ricordare i nomi. :stordita:
Intel è molto più legnosa di quanto sembri, basta pensare alle batoste che ha preso ogni volta che ha cercato di sganciarsi dagli x86 (iapx32, il RISC i860, Itanium)
Vabbé, tiri fuori l'iAPX 432 che non è mai stato nemmeno lontanamente pensato per soppiantare 8086 (http://www.appuntidigitali.it/4151/iapx-432-il-primo-processore-a-32-bit-di-intel-a-oggetti/) & compagnia, mentre l'80860 era un RISC destinato a esplorare nuovi mercati.

L'unico reale successore di x86 sarebbe dovuto essere Itanium, e sappiamo come sia finita.
ed ora ha puntato in modo altrettanto ottuso sulla strategia opposta "solo x86".
Liberandosi anche della divisione ARM. Questo, IMO, bisognerebbe far riflettere. ;)
Se gli ARM cominceranno a far breccia nel mercato dei server, Intel avrà difficoltà a reagire con sufficiente velocità su più fronti (perche anche li come nel settore telefonia e tablet l'attacco arriverà non coordinato su più fronti).
Intanto bisogna vedere se ed eventualmente come ARM farà breccia nel mercato dei server. Il primo reale concorrente, l'X-Gene di APM, non mi sembra che abbia mostrato un quadro diverso (basti vedere il confronto con l'Avoton) (http://www.heise.de/ct/artikel/Prozessorgefluester-1946808.html).

Poi proprio nel mercato server Intel è in continua espansione e sforna nuovi processori che presentano elevate prestazioni unite a consumi contenuti. Per cui non vedo perché non dovrebbe reagire, e pure velocemente.

Idem. Alla fine ciò che succede è continuare, dopo tantissimi anni, ad associare x86 = 8086 = schifezza, senza contestualizzare né riportare fatti a supporto di queste tesi.

P.S. Scusami se ho scritto male il tuo nick, ma non sono ferrato nello ricordare i nomi. :stordita:

Immaginavo.
Comunque, vedremo cosa accadrà in futuro, ma, stando ai dati attuali, non mi sembra che Intel debba temere qualcuno nel settore server.

P.S. Tranquillo, è un nick "demmerda", ma ormai... :D

E' interessante osservare come l'architettura ARM pensata per utilizzi specifici a basso consumo tenti di entrare nel mondo Server di dominio x86... qualcuno ipotizza anche nei PC, per contro invece Intel con i suoi x86 pensati per tutt'altro scopo, cerchi di entrare nel settore mobile...

Invasioni di campo reciproci :D

Intel è molto più legnosa di quanto sembri, basta pensare alle batoste che ha preso ogni volta che ha cercato di sganciarsi dagli x86 (iapx32, il RISC i860, Itanium) ed ora ha puntato in modo altrettanto ottuso sulla strategia opposta "solo x86".


le altre 2 non ho ben presente, ma con Itanium nel quadro generale non gli è mica andata male... ok Itanium è finito male, ma è finito male perchè è stato mangiato, insieme a fette belle grosse della concorrenza, dagli Xeon E7; alla fine sono le altre architetture che hanno subito danni da Intel che sta continuando a fregare fette di mercato nel mercato server.


Con gli Atom mi sembra stia facendo un ottimo lavoro e anche le roadmap è stata accellerata rispetto al passato, anche perchè ha il doppio interesse, visto che Ultra-Mobile, Mobile e Server ad alta densita condividono tutti la stessa architettura base

Immaginavo.
Comunque, vedremo cosa accadrà in futuro, ma, stando ai dati attuali, non mi sembra che Intel debba temere qualcuno nel settore server.

P.S. Tranquillo, è un nick "demmerda", ma ormai... :D
ROFL :D

P.S. Non è possibile spedirti PM. :-/
E' interessante osservare come l'architettura ARM pensata per utilizzi specifici a basso consumo tenti di entrare nel mondo Server di dominio x86... qualcuno ipotizza anche nei PC, per contro invece Intel con i suoi x86 pensati per tutt'altro scopo, cerchi di entrare nel settore mobile...

Invasioni di campo reciproci :D
Entrambi si espandono e cercano di diversificare. Specializzarsi troppo è molto rischioso.

Comunque ARM non è mai stata pensata per il basso consumo, ma per competere a livello prestazionale coi PC.

E c'è da dire che x86 non è certo nata per competere in ambito server. Tutt'altro. Ma s'è rivelata particolarmente portata anche in quest'ambito, e ha fatto fuori diversi RISC blasonati.
le altre 2 non ho ben presente, ma con Itanium nel quadro generale non gli è mica andata male... ok Itanium è finito male, ma è finito male perchè è stato mangiato, insieme a fette belle grosse della concorrenza, dagli Xeon E7; alla fine sono le altre architetture che hanno subito danni da Intel che sta continuando a fregare fette di mercato nel mercato server.
Esattamente. C'è da dire che Itanium avrebbe dovuto effettivamente rappresentare il futuro dei processori Intel, mentre è stata proprio l'architettura che avrebbe dovuto sostituire, x86, a farle sostanzialmente le scarpe.

E' per questo che ormai le ultime soluzioni Xeon hanno anche tecnologia RAS, prima di dominio esclusivo degli Itanium. Gli Xeon sono ormai soluzioni solide e mature.
Con gli Atom mi sembra stia facendo un ottimo lavoro e anche le roadmap è stata accellerata rispetto al passato, anche perchè ha il doppio interesse, visto che Ultra-Mobile, Mobile e Server ad alta densita condividono tutti la stessa architettura base
Già. E aggiungiamo pure la prossima incarnazione di Xeon Phi, Knights Landing, che andrà a completare il quadro coprendo (a mio avviso molto bene; ma vedremo i numeri quando arriverà effettivamente) anche il settore HPC.

Vabbé, tiri fuori l'iAPX 432 che non è mai stato nemmeno lontanamente pensato per soppiantare 8086 (http://www.appuntidigitali.it/4151/iapx-432-il-primo-processore-a-32-bit-di-intel-a-oggetti/) & compagnia, mentre l'80860 era un RISC destinato a esplorare nuovi mercati.

L'unico reale successore di x86 sarebbe dovuto essere Itanium, e sappiamo come sia finita.

iAPX32 era pensato per server e workstation (dove in quel periodo Intel non era presente) ma fu un progetto così disastroso da non arrivare manco sul mercato.

L' i80860 nuovamente era pensato per server e workstation perche in quel periodo i RISC erano più potenti (a parità di step di produzione), ma non trovò nessun produttore di calibro che lo adottasse.

E questo ci porta ad Itanium in cui Intel memore degli errori precedenti si alleò con HP
con un patto di ferro (di cui sta ancora pagando il prezzo visto che è quello che ha tenuto in vita gli Itanium) ma anche li è andata come è andata
(principalmente per "colpa" di AMD che costrinse Intel a continuare a spingere gli x86 quando invece stava chiaramente preparanto il terreno per Itanium).

Di fatto a far "vincere" Intel nel settore server e workstation fu la retrocompatibilità con il software già sviluppato e la spinta combinata di Windows, Netware, Linux e freeBSD
(quando Windows NT "ancora non era pronto", furono gli altri ad aprire davvero la strada)
e di fatto per tali motivi a molti interessavano server che facessero girare più velocemente applicazioni per x86
invece che avere le massime prestazioni in assoluto.
COn il tempo quest erose le quote di mercato dei concorrenti in fasci alta che non poterono più restare competitivi.


Liberandosi anche della divisione ARM. Questo, IMO, bisognerebbe far riflettere. ;)

Se ne liberò perchè era una delle eredità dell'acquisizione degli asset di DEC e non c'era nessuno ai piani alti che si rendesse conto dell'errore che stavano facendo uscendo di fatto dal settore mobile proprio in quel momento.

Infatti ora la vera minaccia non è tanto la crescita di prestazioni a breve degli ARM, ma il fatto che il settore mobile sta erodendo il settore pc/notebook/desktop attualmente dominato dagli x86, causando minori guadagni ad Intel e replicando la stessa dinamica descritta prima, questa volta ai danni di Intel se non riesce ad entrare davvero nel settore mobile.

Se ne liberò perchè era una delle eredità dell'acquisizione degli asset di DEC e non c'era nessuno ai piani alti che si rendesse conto dell'errore che stavano facendo uscendo di fatto dal settore mobile proprio in quel momento.

Infatti ora la vera minaccia non è tanto la crescita di prestazioni a breve degli ARM, ma il fatto che il settore mobile sta erodendo il settore pc/notebook/desktop attualmente dominato dagli x86, causando minori guadagni ad Intel e replicando la stessa dinamica descritta prima, questa volta ai danni di Intel se non riesce ad entrare davvero nel settore mobile.

il problema nel mobile non è stato tanto il liberarsi di ARM, è stato di aver ritardato enormemente lo sviluppo dell'architettura ATOM; quando se ne sono accorti era ormai troppo tardi e ora stanno correndo ai ripari;

http://techreport.com/r.x/2011_5_31_Intels_mobile_roadmap_Ultrabooks_better_Atoms/atom-roadmap.jpg

questa Slide è molto esplicativa di come ora stiano dando priorita ad Atom facendolo uscire non appena diviene disponibile un nuovo pp.

se fossero stati un po piu lungimiranti in questo settore avrebbero fatto uscire BayTrail 6-8 mesi, con conseguente anticipo di tutta la scaletta; fidati avrebbe fatto parecchio la differenza.

iAPX32 era pensato per server e workstation (dove in quel periodo Intel non era presente) ma fu un progetto così disastroso da non arrivare manco sul mercato.

L' i80860 nuovamente era pensato per server e workstation perche in quel periodo i RISC erano più potenti (a parità di step di produzione), ma non trovò nessun produttore di calibro che lo adottasse.
Appunto, ma non sono certi nati perché Intel voleva liberarsi di IA-32!
E questo ci porta ad Itanium in cui Intel memore degli errori precedenti si alleò con HP
con un patto di ferro (di cui sta ancora pagando il prezzo visto che è quello che ha tenuto in vita gli Itanium) ma anche li è andata come è andata
(principalmente per "colpa" di AMD che costrinse Intel a continuare a spingere gli x86 quando invece stava chiaramente preparanto il terreno per Itanium).
Questo è senz'altro vero, colpa anche delle scarse prestazioni che Itanium aveva nell'eseguire la montagna di codice x86 esistente.
Di fatto a far "vincere" Intel nel settore server e workstation fu la retrocompatibilità con il software già sviluppato e la spinta combinata di Windows, Netware, Linux e freeBSD
(quando Windows NT "ancora non era pronto", furono gli altri ad aprire davvero la strada)
e di fatto per tali motivi a molti interessavano server che facessero girare più velocemente applicazioni per x86
invece che avere le massime prestazioni in assoluto.
COn il tempo quest erose le quote di mercato dei concorrenti in fasci alta che non poterono più restare competitivi.
Ma anche no. Nel settore di server e workstation l'assoluta esigenza di compatibilità col codice x86 non c'era proprio. Sono settori in cui hanno sempre dominato soluzioni custom, dove x86 non esisteva nemmeno, e quando c'è entrata non l'ha certo fatto per questioni di compatibilità (con se stessa), ma esclusivamente per il miglior rapporto prestazioni / costo, visto che le soluzioni x86 erano vendute a una frazione del prezzo dei più blasonati RISC.

Certamente da diversi anni è proprio x86 che domina, avendo totalmente ribaltato la situazione, per cui parlare di retrocompatibilità ha senz'altro senso, ma i giochi sono ormai fatti da tempo.
Se ne liberò perchè era una delle eredità dell'acquisizione degli asset di DEC e non c'era nessuno ai piani alti che si rendesse conto dell'errore che stavano facendo uscendo di fatto dal settore mobile proprio in quel momento.
Assolutamente no. Intel se n'è liberata perché XScale era in diretta competizione con la sua stessa architettura, a causa del progetto Atom che era destinato a porre le basi aziendali per il settore low-end & mobile.

L'ho scritto anche in un (ormai vecchio) articolo (http://www.appuntidigitali.it/4375/arm-vs-intel-i-cut-the-power/) (e dunque in tempi "non sospetti"), le cui conclusioni dimostrano esattamente ciò che è avvenuto.

Aggiungo alcune considerazioni molto importanti di cui l'articolo, in quanto vecchio, non tiene conto.

Primo, Intel ha trovato il modo di spegnere il decoder delle istruzioni mediamente nell'80% del tempo, e questo ha contribuito notevolmente ad abbattere i consumi.

Secondo, ormai i 47 milioni dei primi Aton fanno semplicemente ridere, visto che anche nel settore low-end mobile i SoC impiegano centinaia di milioni di transistor. Dunque il peso del decoder (che rimane sempre nell'ordine di qualche milione di transistor) risulta estremamente ridotto sia in termini di silicio sia di consumo.

Terzo, anche i dispositivi low-end sono ormai votati alle prestazioni, e questo significa che le micro-architetture diventano sempre più complesse, richiedendo parecchi transistor per velocizzare l'esecuzione. Tutto ciò si riflette ben poco sul decoder, mentre incide su tutto il resto (code, unità d'esecuzione, retire unit, ecc. ecc.). Al contrario: aumentando i transistor, i decoder diventano via via sempre meno importanti o addirittura trascurabili.
Infatti ora la vera minaccia non è tanto la crescita di prestazioni a breve degli ARM, ma il fatto che il settore mobile sta erodendo il settore pc/notebook/desktop attualmente dominato dagli x86, causando minori guadagni ad Intel e replicando la stessa dinamica descritta prima, questa volta ai danni di Intel se non riesce ad entrare davvero nel settore mobile.
Mi pare che l'enorme avanzata dei tablet sia stata ormai ben ridimensionata, come pure il gran calo delle soluzioni tradizionali. Il mercato, insomma, s'è stabilizzato.

Al contrario, possiamo notare che Intel s'è infilata sia nei tablet sia negli smartphone (uno smartphone non incide nel suo core business; è, invece, un NUOVO settore). Basti vedere anche le ultime notizie, con in cima a tutte le previsioni di vendita di Asus e i suoi ZenPhone (che, ribadisco, è nuovo business per Intel). ;)

Per il resto concordo con AceGranger.

ROFL :D


Entrambi si espandono e cercano di diversificare. Specializzarsi troppo è molto rischioso.

Comunque ARM non è mai stata pensata per il basso consumo, ma per competere a livello prestazionale coi PC.

E c'è da dire che x86 non è certo nata per competere in ambito server. Tutt'altro. Ma s'è rivelata particolarmente portata anche in quest'ambito, e ha fatto fuori diversi RISC blasonati.

.

In effetti l'architettura ARM è nata da Acorn Computer per migliorare il MOS 6502 anche se nel tempo ha trovato impiego nei sistemi embedded.

Però oserei dire che per anni ARM e x86 sono rimaste separate in settori diversi, fino a quando i numeri sul campo hanno preso una piega imprevista fino oggi, ora entrambi cercano di conquistare spazi che prima non avevano...

Assolutamente d'accordo.

Appunto, ma non sono certi nati perché Intel voleva liberarsi di IA-32!

Erano nati perche in quel periodo Intel non credeva che gli x86 potessero sfondare in quel settore dive a quel tempo a dominare erano le prestazioni.
Infatti poi alla fine riuscì a sfondare perche con il continuo progresso tecnologico
(e gli introiti che derivavano dal settore dei pc x86 "desktop/notebook" che permiseto ad Intel di procedere di step in step) i sistemi x86 divennero sufficientemente potenti ed economici da cominciare ad entrare nella fascia bassa dei server e da li continuare a crescere sempre più.
Solo quando il settore dei server fu sufficientemente eroso da Intel i concorrenti si ritrovarono a non essere più in grado di competere step dopo step ed iniziarono a perdere sempre più terreno.

Questo è senz'altro vero, colpa anche delle scarse prestazioni che Itanium aveva nell'eseguire la montagna di codice x86 esistente.

Il vero problema di Itanium era che non aveva problemi di prestazioni anche
quando eseguiva codice compilato appositamente per esso.
Il Merced era patetico sui calcoli interi (e per clienti che eseguivano codice dominato dai calcoli sugli interi era una cosa imbarazzante visto che i sistemi legacy ancora in commercio avevano prestazioni superiori proprio in tale ambito).
Poi la concorrenza tra AMD ed Intel fece il resto dandouna spinta decisiva alle prestazioni degli x86 anche sui calcoli in floating point.
Ma non dimentichiamoci che la vera architettura dominante in termini di prestazioni e che fu messa fuori gioco da accordi commerciali era l'Alpha, quello che non più aggiornato a livello di nuovi design che sfruttassero gli step più avanzati e solo shrinkato in economia e con molto ritardo faceva ancora a pezzi gli Itanium.

Ma anche no. Nel settore di server e workstation l'assoluta esigenza di compatibilità col codice x86 non c'era proprio. Sono settori in cui hanno sempre dominato soluzioni custom, dove x86 non esisteva nemmeno, e quando c'è entrata non l'ha certo fatto per questioni di compatibilità (con se stessa), ma esclusivamente per il miglior rapporto prestazioni / costo, visto che le soluzioni x86 erano vendute a una frazione del prezzo dei più blasonati RISC.

Ma era rilevante per l'erosione "dal basso" del settore.
Da un lato avevi produttori che ti vendevano hardware e software e con un lock-in notevole.
Dall'altro con un x86 a 32bit "generico" ci buttavi su Netware, Linux o Windows NT ed avevi funzionalità per cui prima ti toccava comprare roba più costosa, con un lock-in molto più limitato da parte dei produttori dell'hardware (e quindi necessariamente con meno ricarichi rispetto per restare competitivi).
Poi è da notare che i primi prodotti "di fascia alta" a venir fatti fuori furono le workstation "professionali" (dove a differenza che con i server, il vantaggio di far girare codice x86 si è fatto sentire prima).

In effetti l'architettura ARM è nata da Acorn Computer per migliorare il MOS 6502 anche se nel tempo ha trovato impiego nei sistemi embedded.

E non a caso in quel periodo i primi ARM in termini di prestazioni ...
letteralmente DISINTEGRAVANO gli x86 più potenti. :read:

L' ARM2 con 30mila gate clockato ad 8 Mhz faceva a pezzi gli 80286 con 134mila gate clockati a 10Mhz.
E questo già allora con consumi bassissimi che fecero la sua fortuna nel settore embedded e mobile.

Il punto è che nelle iterazioni successive l'enfasi fu posta sull'efficienza (MIPS per Watt) e sui bassi consumi in generale visto che era li che gli ARM trovavano spazio.


Però oserei dire che per anni ARM e x86 sono rimaste separate in settori diversi, fino a quando i numeri sul campo hanno preso una piega imprevista fino oggi, ora entrambi cercano di conquistare spazi che prima non avevano...

Infatti, per questo sono decenni che NON SI VEDONO ANCORA nuovi progetti di core ARM che hanno come obiettivo le prestazioni con TDP "da desktop".

Basta pensare che per gli A72 a 10nm il consumo massimo previsto è 1.2Watt per core a 2.5Ghz (http://www.fudzilla.com/news/processors/37583-arm-10nm-and-16nm-finfet-cortex-designs-leaked).

Non a caso proprio perchè i core consumano così poco diventa conveniente adottare soluzione come l' MT6797 "huge-Medium-Tiny" a 10 core (http://www.fudzilla.com/news/processors/37582-mediatek-10-core-soc-employs-huge-medium-tiny-design) (2 core A72 a 2.5Ghz, 4 core A53 a 2.0 Ghz e 4 core A53 a 1.4Ghz).

Questo perche 4 core A53 occupano circa l'area di un A72 e gli A53 possono essere ottimizzati a livello circuitale per operare al meglio a frequenze specifiche con ritocchi minimi.

Erano nati perche in quel periodo Intel non credeva che gli x86 potessero sfondare in quel settore dive a quel tempo a dominare erano le prestazioni.
Infatti poi alla fine riuscì a sfondare perche con il continuo progresso tecnologico
(e gli introiti che derivavano dal settore dei pc x86 "desktop/notebook" che permiseto ad Intel di procedere di step in step) i sistemi x86 divennero sufficientemente potenti ed economici da cominciare ad entrare nella fascia bassa dei server e da li continuare a crescere sempre più.
Solo quando il settore dei server fu sufficientemente eroso da Intel i concorrenti si ritrovarono a non essere più in grado di competere step dopo step ed iniziarono a perdere sempre più terreno.
Scusami, ma l'iAPX 432 è un progetto che è nato nel 1975, dunque prima dell'8086, e che è stato rilasciato (e subito ucciso) nel 1981, quando cioé i PC erano appena nati (agosto 1981) e il loro enorme successo era ancora da venire.

Il tuo discorso si potrebbe applicare al più all'80860 (ma assolutamente no all'iAPX 432), se non fosse che Intel aveva già rilasciato un altro processore (anch'esso RISC), l'80960, quale "erede" dell'iAPX 432, e dunque con le stesse ambizioni nonché segmento di mercato da attaccare. Ancora una volta, di rimpiazzare l'8086 non se ne parla proprio, visti anche i tempi (l'i960 è un progetto del 1984 e commercializzato l'anno successivo).

Infine l'i860 s'inserisce, ancora una volta, nello stesso filone/trend, che è quello di sfondare nel mercato di workstation & server, con un chip ad elevate prestazioni.

In tutto ciò di rimpiazzare IA-32 non se ne parla assolutamente, perché si tratta di mercati a esso del tutto alieni. Intel inizierà a competere in questi mercati soltanto con l'introduzione dell'80486 (stesso anno dell'i860), grazie alle elevate prestazioni (15 MIPS e 1 MFLOPS a 25Mhz) e al basso prezzo.

Per essere precisi, non fu tanto Intel a spingere in questa direzione, ma i produttori di workstation (in primis) e server ad accorgersi che un 486 era più conveniente di tanti RISC, grazie all'ottimo rapporto prestazioni/prezzo. Perfino Sun propose workstation basate su 486, pur potendo contare sui suoi famosi SPARC.
Il vero problema di Itanium era che non aveva problemi di prestazioni anche
quando eseguiva codice compilato appositamente per esso.
Il Merced era patetico sui calcoli interi (e per clienti che eseguivano codice dominato dai calcoli sugli interi era una cosa imbarazzante visto che i sistemi legacy ancora in commercio avevano prestazioni superiori proprio in tale ambito).
Sì, ma Merced fu anche la prima versione di Itanium. Le prestazioni erano scarse, tranne per la virgola mobile.

Itanium 2, presentato l'anno dopo, risolse molti dei problemi prestazionali.
Poi la concorrenza tra AMD ed Intel fece il resto dandouna spinta decisiva alle prestazioni degli x86 anche sui calcoli in floating point.
Più che altro è stata l'introduzione di x86-64 da parte di AMD ha sparigliare le carte di Intel con Itanium.
Ma non dimentichiamoci che la vera architettura dominante in termini di prestazioni e che fu messa fuori gioco da accordi commerciali era l'Alpha, quello che non più aggiornato a livello di nuovi design che sfruttassero gli step più avanzati e solo shrinkato in economia e con molto ritardo faceva ancora a pezzi gli Itanium.
Senz'altro, Alpha era un'architettura estremamente votata alla prestazioni, ma anche... energivora. Considera che già all'epoca era Out-of-Order e in grado di decodificare ed eseguire ben 4 istruzioni per ciclo di clock.

Se consideriamo che il Cortex-A72 annunciato da ARM giusto qualche giorno fa è in grado di decodificarne 3 ed eseguirne un massimo 5, ci può fare un'idea del mostro che Alpha era già allora.

Ma, allo stesso tempo, si può anche capire che un design già così avanzato all'epoca non avrebbe potuto continuare a spingere così tanto sulle prestazioni.
Ma era rilevante per l'erosione "dal basso" del settore.
Da un lato avevi produttori che ti vendevano hardware e software e con un lock-in notevole.
Dall'altro con un x86 a 32bit "generico" ci buttavi su Netware, Linux o Windows NT ed avevi funzionalità per cui prima ti toccava comprare roba più costosa, con un lock-in molto più limitato da parte dei produttori dell'hardware (e quindi necessariamente con meno ricarichi rispetto per restare competitivi).
Poi è da notare che i primi prodotti "di fascia alta" a venir fatti fuori furono le workstation "professionali" (dove a differenza che con i server, il vantaggio di far girare codice x86 si è fatto sentire prima).
Sì, ma è stato un processo graduale portato su due fronti: la vendita di sistemi x86 con buon (poi ottino) rapporto prestazioni / prezzo, e l'introduzione di software adeguato per quest'architettura.

Oggi quando guardiamo al mercato server lo associamo a Intel, ma una ventina d'anni fa non era affatto così, e prima era praticamente inesistente.
E non a caso in quel periodo i primi ARM in termini di prestazioni ...
letteralmente DISINTEGRAVANO gli x86 più potenti. :read:

L' ARM2 con 30mila gate clockato ad 8 Mhz faceva a pezzi gli 80286 con 134mila gate clockati a 10Mhz.
Finché non arrivano 80486 per Intel e, soprattutto, 68040 per Motorola. :cool:
E questo già allora con consumi bassissimi che fecero la sua fortuna nel settore embedded e mobile.
Nel settore embedded ARM entrerà soltanto nei primi anni '90, quando ormai quello desktop era perso. Un po' di anni dopo entrerà anche in quello mobile.
Il punto è che nelle iterazioni successive l'enfasi fu posta sull'efficienza (MIPS per Watt) e sui bassi consumi in generale visto che era li che gli ARM trovavano spazio.
Beh, trovavano spazio anche tanti altri RISC che erano pure molto più semplici degli ARM (che rimane un'architettura RISC fra le più complicate).

ARM è riuscita a sfondare, invece, col suo modello vincente di licensing delle sue architetture.
Infatti, per questo sono decenni che NON SI VEDONO ANCORA nuovi progetti di core ARM che hanno come obiettivo le prestazioni con TDP "da desktop".
Pardon, ma Apple A8 e nVidia Denver non sono progetti nuovi, con micro-architetture estremamente votate alle prestazioni, e prestazioni allineate a quelle dei desktop?
Basta pensare che per gli A72 a 10nm il consumo massimo previsto è 1.2Watt per core a 2.5Ghz (http://www.fudzilla.com/news/processors/37583-arm-10nm-and-16nm-finfet-cortex-designs-leaked).

Non a caso proprio perchè i core consumano così poco diventa conveniente adottare soluzione come l' MT6797 "huge-Medium-Tiny" a 10 core (http://www.fudzilla.com/news/processors/37582-mediatek-10-core-soc-employs-huge-medium-tiny-design) (2 core A72 a 2.5Ghz, 4 core A53 a 2.0 Ghz e 4 core A53 a 1.4Ghz).

Questo perche 4 core A53 occupano circa l'area di un A72 e gli A53 possono essere ottimizzati a livello circuitale per operare al meglio a frequenze specifiche con ritocchi minimi.
Il che fa capire bene cosa significhi ottenere prestazioni elevate: serve avere tanto silicio. ;)

Scusami, ma l'iAPX 432 è un progetto che è nato nel 1975, dunque prima dell'8086, e che è stato rilasciato (e subito ucciso) nel 1981, quando cioé i PC erano appena nati (agosto 1981) e il loro enorme successo era ancora da venire.

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.

Il tuo discorso si potrebbe applicare al più all'80860 (ma assolutamente no all'iAPX 432), se non fosse che Intel aveva già rilasciato un altro processore (anch'esso RISC), l'80960, quale "erede" dell'iAPX 432, e dunque con le stesse ambizioni nonché segmento di mercato da attaccare. Ancora una volta, di rimpiazzare l'8086 non se ne parla proprio, visti anche i tempi (l'i960 è un progetto del 1984 e commercializzato l'anno successivo).

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

Infine l'i860 s'inserisce, ancora una volta, nello stesso filone/trend, che è quello di sfondare nel mercato di workstation & server, con un chip ad elevate prestazioni.

In tutto ciò di rimpiazzare IA-32 non se ne parla assolutamente, perché si tratta di mercati a esso del tutto alieni. Intel inizierà a competere in questi mercati soltanto con l'introduzione dell'80486 (stesso anno dell'i860), grazie alle elevate prestazioni (15 MIPS e 1 MFLOPS a 25Mhz) e al basso prezzo.

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

Per essere precisi, non fu tanto Intel a spingere in questa direzione, ma i produttori di workstation (in primis) e server ad accorgersi che un 486 era più conveniente di tanti RISC, grazie all'ottimo rapporto prestazioni/prezzo. Perfino Sun propose workstation basate su 486, pur potendo contare sui suoi famosi SPARC.

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

Sì, ma Merced fu anche la prima versione di Itanium. Le prestazioni erano scarse, tranne per la virgola mobile.

Itanium 2, presentato l'anno dopo, risolse molti dei problemi prestazionali.

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

Più che altro è stata l'introduzione di x86-64 da parte di AMD ha sparigliare le carte di Intel con Itanium.

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.

Senz'altro, Alpha era un'architettura estremamente votata alla prestazioni, ma anche... energivora. Considera che già all'epoca era Out-of-Order e in grado di decodificare ed eseguire ben 4 istruzioni per ciclo di clock.

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

Se consideriamo che il Cortex-A72 annunciato da ARM giusto qualche giorno fa è in grado di decodificarne 3 ed eseguirne un massimo 5, ci può fare un'idea del mostro che Alpha era già allora.

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

Ma, allo stesso tempo, si può anche capire che un design già così avanzato all'epoca non avrebbe potuto continuare a spingere così tanto sulle prestazioni.

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

Nel settore embedded ARM entrerà soltanto nei primi anni '90, quando ormai quello desktop era perso. Un po' di anni dopo entrerà anche in quello mobile.

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

ARM è riuscita a sfondare, invece, col suo modello vincente di licensing delle sue architetture.
Quello è uno dei fattori che hanno contribuito al suo successo, ma senza una buona architettura di base non sarebbe bastato.

Pardon, ma Apple A8 e nVidia Denver non sono progetti nuovi, con micro-architetture estremamente votate alle prestazioni, e prestazioni allineate a quelle dei desktop?
Ma che devono operare con i budget energetici molto limitati degli smartphone e dei tablet. ;)

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).
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.
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.
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).
Il Cortex-A72 è pensato per consumi massimi bassissimi rispetto a quelli ritenuti "nella media" per gli Alpha.
Vero, ma volevo sottolineare come già all'epoca quella di Alpha fosse un'architettura molto tirata.
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).
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.
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. :eek:
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 (http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1003586&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F7869%2F21664%2F01003586.pdf%3Farnumber%3D1003586) 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.
Quello è uno dei fattori che hanno contribuito al suo successo, ma senza una buona architettura di base non sarebbe bastato.
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.
Ma che devono operare con i budget energetici molto limitati degli smartphone e dei tablet. ;)
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.

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.

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

Ad esempio in quest'articolo (http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1003586&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F7869%2F21664%2F01003586.pdf%3Farnumber%3D1003586) 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.

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.

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

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)

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.

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.
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.
In parte ricorda il design di Xeon Phi, dove l'unità scalare è separata da quella vettoriale, anche se condividono entrambe le cache.
Il vbox (il core vettoriale) di Tarantula si interfacciava direttamente 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).
Non poteva essere altrimenti, perché la cache L1 era troppo piccola per poter soddisfare la fame di bandwidth di VBox.
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).
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. ;)
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.
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.
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)
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.
La cache L2 era partizionata in 16 banchi, probabilmente le prime implementazioni sarebbero stare degli MCM (Multi Chip module) con più "chip L2" dedicati.
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.
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.
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. ;)

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

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.

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