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

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

ROFL

P.S. Non è possibile spedirti PM. :-/

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.

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.

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.

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.



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;

Link ad immagine (click per visualizzarla)

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.

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

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

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.

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

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.

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.

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.



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

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

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.




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.

Non a caso proprio perchè i core consumano così poco diventa conveniente adottare soluzione come l' MT6797 "huge-Medium-Tiny" a 10 core (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.

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.

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.

Più che altro è stata l'introduzione di x86-64 da parte di AMD ha sparigliare le carte di Intel con 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.

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.

Finché non arrivano 80486 per Intel e, soprattutto, 68040 per Motorola.

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.

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.

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?

Il che fa capire bene cosa significhi ottenere prestazioni elevate: serve avere tanto silicio.