Apple, ritornano le voci sul passaggio ad ARM per desktop e portatili

[jined]

Ha un certo senso, ma ci vogliono almeno altre 3 generazioni di SoC Arm prima di parlarne.

Diciamo, effettivo dall'anno 2020.

Hanno ancora tutto il tempo di aggiornare la linea Mac Pro

[Cfranco]

Originariamente inviato da LMCH

Con un calcolo spannomentrico, a parità di tecnologia di produzione si potrebbe realizzare un core ARM con minimo il doppio dei thread rispetto ad un x86.
Anche a parità di prestazioni per thread, il maggior numero di thread eseguibili in parallelo gli darebbe un bel vantaggio.

Non diciamo sciocchezze
La parte decoder è minima e il vantaggio di arm su Intel non esiste, anzi probabilmente è la seconda in posizione di vantaggio grazie all' immenso know-how e ai fondi smisurati.
Arm ha già provato in passato a contrastare Intel e ne è uscita a pezzi, è relativamente facile produrre una cpu nuova e ottenere grandi prestazioni, ci sono riusciti in tanti ( anche Motorola, Sun, AMD e IBM lo hanno fatto ), il problema è restare in vetta senza perdere il ritmo.

[pirlano]

Originariamente inviato da ld50

windows 8 punta tutto sul consumer.

Originariamente inviato da ld50

Forse dovremo buttarci tutti su windows 7, che tuttavia ha ancora al max 5-8 anni di supporto garantiti da casa microsoft

1)Io non capisco perchè reputi Win7 buono e Win8 spazzatura. Win8 è più veloce, reattivo, leggero, occupa meno ram, si accende e si spegne in un quarto del tempo di Win7, sicurezza migliore, migliorie ovunque...
2)Le licenze costano anche meno.
3)L'interfaccia metro non influenza NIENTE per quanto riguarda la produttività (anzi hanno aggiunto molte scorciatoie con le hotkey da tastiera comodissime).
Win+Q, scrivi "photos" e photoshop è già li, premi Invio e si apre
Win+Q, scrivi "blend" e blender è già li, premi Invio, fine.
Oppure te li metti nella barra delle applicazioni sotto
Ad aprire i programmi ci vuole pochissimo, una volta aperti che ti cambia?
Io non capisco...io che uso il computer per lavorare, lo accendo e l'unico pulsante "Metro" che premo è "Desktop". Fine.

Originariamente inviato da ld50

e che non è comunque al livello di osx.

un dual boot Win8 + CentOS e ho tutto
OSX non fa nè le cose di Win8 nè le cose di Linux, è una via di mezzo inutile (per il mio utilizzo, non metto assolutamente in dubbio che sia un ottimo OS)
Poi magari chi usa programmi particolari si trova meglio con OSX, ma non è sempre vero in generale, a ognuno il suo

[LMCH]

Originariamente inviato da Cfranco

Non diciamo sciocchezze
La parte decoder è minima e il vantaggio di arm su Intel non esiste, anzi probabilmente è la seconda in posizione di vantaggio grazie all' immenso know-how e ai fondi smisurati.

Stai facendo troppa confusione tra architetture di cpu ed aziende.

Non a caso ho scritto "se AMD decidesse di applicare tutto il know how che ha in termini di capacità di sviluppare roba ad alte prestazioni e tirata al limite dell'inviluppo di potenza ...".
AMD non ARM ltd.
AMD ha il know-how necessario e le risorse per tirar fuori degli ARM ad alte prestazioni, non ARM ltd (che continua ad avere il suo core business come fornitore di IP, non come produttore/venditore di hardware).

Poi è vero che la parte decoder sulle cpu per desktop/server è "minima" rispetto al resto, ma non è così ininfluente come potrebbe sembrare a prima vista.

Pensa ad esempio al flop clamoroso di IA64 dovuto in primo luogo al suo set d'istruzioni ed a quello che implicava a cascata riguardo banda di I/O, decoder ed unità di esecuzione.
Nonostante Intel ci si sia svenata dietro in tutti i modi ormai sopravvive solo grazie al contratto capestro di HP che impone ad Intel di continuare a supportare tale cpu.
Ed infatti dopo quella batosta Intel se ne è uscita con la sua attuale strategia "x86 ovunque".

Originariamente inviato da Cfranco

Arm ha già provato in passato a contrastare Intel e ne è uscita a pezzi, è relativamente facile produrre una cpu nuova e ottenere grandi prestazioni, ci sono riusciti in tanti ( anche Motorola, Sun, AMD e IBM lo hanno fatto ), il problema è restare in vetta senza perdere il ritmo.

No, ARM Ltd. a suo tempo si è concentrata sulla progettazione e la vendita di licenze ed Proprietà Intellettuali per il settore embedded e mobile, non ha mai provato a contrastare Intel sui desktop e sui server.
Al massimo i primi ARM sono stati usati su home computer (e come potenza di calcolo erano più potenti dei corrispettivi x86 del periodo, usando pure meno gate sul chip) ma poi praticamente più niente in tal senso, al massimo PDA e smartphone, solo ora con tablet e smarphone sempre più potenti (e con la nuova architettura a 64bit) potrebbe iniziare l'attacco verso i desktop.

[Asterion]

Proprio ora che i Mac hanno buone prestazioni vogliono utilizzare processori meno potenti?

[JackZR]

Originariamente inviato da pirlano

1)Io non capisco perchè reputi Win7 buono e Win8 spazzatura. Win8 è più veloce, reattivo, leggero, occupa meno ram, si accende e si spegne in un quarto del tempo di Win7, sicurezza migliore, migliorie ovunque...
2)Le licenze costano anche meno.
3)L'interfaccia metro non influenza NIENTE per quanto riguarda la produttività (anzi hanno aggiunto molte scorciatoie con le hotkey da tastiera comodissime).
Win+Q, scrivi "photos" e photoshop è già li, premi Invio e si apre
Win+Q, scrivi "blend" e blender è già li, premi Invio, fine.
Oppure te li metti nella barra delle applicazioni sotto
Ad aprire i programmi ci vuole pochissimo, una volta aperti che ti cambia?
Io non capisco...io che uso il computer per lavorare, lo accendo e l'unico pulsante "Metro" che premo è "Desktop". Fine.


un dual boot Win8 + CentOS e ho tutto
OSX non fa nè le cose di Win8 nè le cose di Linux, è una via di mezzo inutile (per il mio utilizzo, non metto assolutamente in dubbio che sia un ottimo OS)
Poi magari chi usa programmi particolari si trova meglio con OSX, ma non è sempre vero in generale, a ognuno il suo

Quoto tutto.

Originariamente inviato da Asterion

Proprio ora che i Mac hanno buone prestazioni vogliono utilizzare processori meno potenti?

A loro non gli interessa come vano le macchine, gli basta che siano una cosa tutta loro che venda.

[Baboo85]

Sinceramente non la vedo male questa transizione.

Sono piattaforme diverse, e' vero, ma io guarderei un po' la differenza prestazionale... Su un dispositivo che consuma pochi milliwatt (per quanto sia un quad core tegra 3 sticazzi e mazzi) ci girano giochi che tra poco arrivano al livello delle console.

Un x86 e' un'architettura diversa, ma se penso che con un ARM ci faccio le stesse cose (e anche di piu') con un consumo irrisorio e un calore generato quasi nullo... Le dimensioni di un netbook... E lo dimostrera' bene Windows 8 su ARM.


Cosi' comunque Apple avrebbe anche il vantaggio di fare un OS unico ma con una GUI diversa a seconda se e' un iP-qualcosa o un MacBook-qualsiasi. Oppure fara' come Microsoft e fara' una GUI unica per tutti i dispositivi.


Per quanto Apple non mi possa piacere, i suoi prodotti non sono schifezze (anche se il prezzo e' alto e io al massimo li prendo usati a poco) e le scelte che fa di abbandonare certi standard (attenzione, abbandonare, non cambiare) non e' per nulla un male.
Che io sappia e' stata la prima a dire "basta ai floppy", "basta alle unita' ottiche" e ora "basta a x86".

La vera capacita' di Apple non e' quella di inventare cose, ma far cambiare tendenza alle persone e alle aziende. Nessuno si cag*va di striscio i palmari/cellulari, arriva iPhone e tutti a comprare e produrre cellulari touch. Nessuno pensava ai tablet come dispositivi da utilizzare, arriva lei a farne uno e tutti a fare tablet. Idem per l'Air, sottile, leggero e giu' a fare gli ultrabook.
L'iPod touch, che io sappia, e' l'unico lettore mp3/mp4 multimediale dove ci puoi installare anche delle app. Se esistono anche quelli Android (tipo forse gli Archos) quasi nessuno li sente mai nominare.
Forse forse (parlo sempre per "quello che ne so io") anche gli all-in-one sono stati commercializzati pesantemente (quindi non inventati, ma commercializzati) la prima volta da Apple.
E del mac-mini? Per quanto si voglia e possa dire, e' l'unico nel suo genere cosi' potente e a quel prezzo.
E come estetica (che puo' non piacere) sinceramente e' una bella linea. Io ho sempre sbavato sull'Air e sull'iMac della Apple (l'Air, usato, ora ce l'ho e pagato poco con su Windows 7 in dual boot).


Questa e' una cosa che apprezzo di Apple, sinceramente. Poi che costringa i clienti ad utilizzare il dispositivo come vogliono loro (con restrizioni all'OS, blindature varie, ecc) e' gia' una cosa che fa girare i maroni, cosi' come i prezzi assurdi.
Ma non e' colpa loro se la gente fa la fila dormendo davanti agli Apple Store e pestandosi per gli ultimi iPhone del day-one (quando basterebbe starsene tranquilli e comprarlo i giorni successivi)...


EDIT: ah, prima che partano commenti vari... Io odio Apple ma non i suoi prodotti (i prezzi si'), ho un Android (HTC Desire HD con MIUI Jelly Bean) come smartphone dopo aver passato anni con Nokia e Symbian, un iPod 2G preso usato quando il vecchio Creative Zen (si', quello con schermo in bianco e nero) e' saltato, un Asus G51JX preso personalmente a New York come notebook gaming (firma), un Air 2010 (con la GT 320M) preso usato dall'america per spendere poco con Windows 7 in dual boot... Quindi non sto tanto a guardare chi o cosa crea un prodotto, ma sto a guardare cosa conviene comprare sia per il prezzo (usato o nuovo), sia per la dotazione e le capacita' di un dispositivo (potevo prendere un lettore MP3 qualsiasi, ma ho preferito un piu' evoluto iPod e sono contento cosi', l'Air mi piaceva ed e' comodo da trasportare (forse pero' se aspettavo il modello successivo che hanno fatto anche l'11"...), un iPhone costa troppo e non si puo' cambiare la batteria, inoltre ero abituato agli smanettamenti su Symbian quindi ho preferito Android).

[birmarco]

Originariamente inviato da LMCH

Ai tempi che furono l'ARM2 realizzato con un quarto dei transitor dell'80286 gli spaccava il cuBo a colpi di pura potenza di calcolo.

Solo che poi mentre Intel con gli x86 si è concentrata su cpu per desktop e server, ARM ha invece privilegiato le soluzioni embedded e mobile (dove una volta raggiunto un certo livello di potenza di calcolo, la cosa più importante è che un chip costi poco e consumi poco).

Ma se poniamo AMD decidesse di applicare tutto il know how che ha in termini di capacità di sviluppare roba ad alte prestazioni e tirata al limite dell'inviluppo di potenza, ci metterebbe poco a realizzare una cpu ARM capace di competere ad armi pari con gli x86.
Questo perchè il decoder istruzioni degli ARM è molto più semplice ed efficiente di quello degli x86 mentre tutta la roba "dopo il decoder" può essere adattata in tempi relativamente ridotti.

Con un calcolo spannomentrico, a parità di tecnologia di produzione si potrebbe realizzare un core ARM con minimo il doppio dei thread rispetto ad un x86.
Anche a parità di prestazioni per thread, il maggior numero di thread eseguibili in parallelo gli darebbe un bel vantaggio.

Rimane il problema delle vecchie applicazioni disponibili solo per x86, ma su questo lato Apple ha di gran lunga meno problemi rispetto a Microsoft (senza contare che pure Microsoft sta spingendo da anni gli sviluppatori a non dipendere dall'architettura x86 sebbene la cosa proceda per le lunghe).

Ieri avevo scritto un bel post, ma HWU se l'è mangiato

E riscriviamo!

Secondo me quello che dici è giusto ma non considera una cosa fondamentale: la ricchezza di Intel. Intel è un'azienda che ha dalla sua fondi, fabbriche e know-how necessari per sviluppare al massimo x86. Sarà anche un'architettura inefficiente e obesa (Atom ne è uno degli ultimi esempi) ma riesce a garantire un buon livello di potenza, e con quei tre elementi di poco fa Intel ci metterebbe poco a farla spingere al massimo. A suon di riduzioni di PP la fanno sembrare sempre più efficiente, e di fatto quello che conta è il consumo effettivo.

ARM può sperare con AMD ma non sarebbe in grado di competere per un ingresso di punta nel mercato, non ha le risorse necessarie. In più dovrebbero appoggiarsi a TMSC (che ultimamente non brilla) e Globalfoundries, ma le rese produttive potrebbero non essere sufficienti.

Quindi si potrebbe fare si un ARM bello carrozzato ma di fatto avrebbe lo stesso consumo di Intel, dato che Intel potrebbe sempre scendere di PP. Ma si porterebbe dietro gli svantaggi di non avere software. La storia ci insegna che niente software = FALLIMENTO. Vedi Symbian che è fallito alla velocità della luce, di recente. Apple come spera di garantire questo cambio radicale mantenendo tutti i software? I big potrebbero reagire male e rilasciare con lentezza o cmq sfornare sw non troppo ottimizzato. Se fino al giorno prima, Adobe per esempio, deve fare Photoshop per il Mac con Intel, non può passare di colpo a Photoshop per ARM. Ci vuole tempo. E nel frattempo che si fa? QUando esce quello nuovo, le patch per il vecchio? Anche il vecchio andrebbe mantenuto in sviluppo. Costi, costi e costi. Col passaggio PowerPC->Intel era diverso perchè Win aveva già x86 e quindi si poteva riciclare parecchio da lì. Ma ora ci sarebbe da fare un grosso lavoro, come testimonia Windows 8 RT. Apple potrebbe perdere di colpo tutta la fascia professionisti che già sono inca**ati perchè di fatto li stanno già abbandonando. Ma se fanno brutti scherzi anche a quei professionisti meno esigenti che gli bastano quei due SW per essere contenti, potrebbero perdere tutto il mercato PC, o cmq una buona fetta.

Visto che il mercato mobile tira parecchio Apple sta facendo i soldi con quelli ma non può sperare di rimanere SOLO con quelli. I dati parlano chiaro. Samsung sta acquisendo quote di mercato e sono pronto a scommettere che anche Nokia-MS con Win Phone 8 farà un ingresso molto più aggressivo di Win Phone 7. Non che Cook debba rinunciare ai suoi sogni tranquilli, ma fai iniziare l'erosione di quote di mercato in un settore dove fino al giorno prima eri in espansione... Non è così rosea la situazione. GLi investitori potrebbero perdere fiducia, e visto che Apple vale quel che vale anche e soprattutto per il mercato virtuale speculativo potrebbe scendere in picco.

IMHO, ad entrare così nel mercato ARM, Apple si butta nel vuoto senza paracadute. Soprattutto per il modo in cui vuole farlo, dato che sicuramente vorrà anche la SUA CPU e non si accontenterà di stringere accordi con AMD, nVidia o altro...

[Baboo85]

Originariamente inviato da birmarco

Ma si porterebbe dietro gli svantaggi di non avere software. La storia ci insegna che niente software = FALLIMENTO. Vedi Symbian che è fallito alla velocità della luce, di recente. Apple come spera di garantire questo cambio radicale mantenendo tutti i software? I big potrebbero reagire male e rilasciare con lentezza o cmq sfornare sw non troppo ottimizzato. Se fino al giorno prima, Adobe per esempio, deve fare Photoshop per il Mac con Intel, non può passare di colpo a Photoshop per ARM. Ci vuole tempo. E nel frattempo che si fa? QUando esce quello nuovo, le patch per il vecchio? Anche il vecchio andrebbe mantenuto in sviluppo.

https://itunes.apple.com/it/app/adob...331975235?mt=8

Se gia' esiste questo, ci vuole poco a fare quello completo.

Forse tu, come altri, non vi rendete conto di una cosa: se Apple cambia, anche gli altri cambiano (come ho appena scritto sopra).
Windows 8 e' gia' su piattaforma ARM, ora anche Apple. Credi che Adobe e le altre aziende non si mettano a produrre software per ARM? Ma dai...

Gia' la mela di suo e' un bel trattore (ripeto: mio post sopra), se poi c'e' anche Windows... E contiamo che molte distro Linux gia' vanno su ARM, senza menzionare Android.

Non mi sembra che ci sia tutto sto casino che dici tu. Anzi, al contrario di quello che hai detto tu (che non ho quotato) e' Intel che si deve spaventare di ARM e non ARM che fara' fatica a spuntare fuori anche nei pc...

E pure AMD si deve spaventare, il doppio, non solo sul fronte CPU ma anche GPU visto che Nvidia e' gia' fuori con Tegra da mesi e mesi.

Originariamente inviato da birmarco

Apple potrebbe perdere di colpo tutta la fascia professionisti che già sono inca**ati perchè di fatto li stanno già abbandonando. Ma se fanno brutti scherzi anche a quei professionisti meno esigenti che gli bastano quei due SW per essere contenti, potrebbero perdere tutto il mercato PC, o cmq una buona fetta.

Se il mercato cambia, anche i professionisti si adeguano, altrimenti non "professano" piu' nulla, fidati.

Originariamente inviato da birmarco

Visto che il mercato mobile tira parecchio Apple sta facendo i soldi con quelli ma non può sperare di rimanere SOLO con quelli. I dati parlano chiaro. Samsung sta acquisendo quote di mercato e sono pronto a scommettere che anche Nokia-MS con Win Phone 8 farà un ingresso molto più aggressivo di Win Phone 7. Non che Cook debba rinunciare ai suoi sogni tranquilli, ma fai iniziare l'erosione di quote di mercato in un settore dove fino al giorno prima eri in espansione... Non è così rosea la situazione. GLi investitori potrebbero perdere fiducia, e visto che Apple vale quel che vale anche e soprattutto per il mercato virtuale speculativo potrebbe scendere in picco.

Quello potrebbe anche succedere rimanendo su x86...

Originariamente inviato da birmarco

IMHO, ad entrare così nel mercato ARM, Apple si butta nel vuoto senza paracadute. Soprattutto per il modo in cui vuole farlo, dato che sicuramente vorrà anche la SUA CPU e non si accontenterà di stringere accordi con AMD, nVidia o altro...

Quale sua CPU... Fino a poco fa i chip ARM degli iphone erano della Samsung... Apple non produce nulla di suo, se non il software. I componenti hardware sono fatti da altri (CPU intel e samsung, ssd intel o salcavolo, schede video nvidia, ecc). Lei ci mette software e design.

Semplicemente potrebbe passare a Tegra o Qualcomm, dov'e' il problema... Anzi, cerchera' di mantenere compatibilita' con quelli di iPhone e iPad in modo che una stessa app possa essere sviluppata per tutti i dispositivi con poche modifiche da fare (ovviamente senza dare la possibilita' che un'app per un iMac funzioni per iPhone, anche perche' su iMac hai tastiera e mouse...).

[birmarco]

Originariamente inviato da Baboo85

https://itunes.apple.com/it/app/adob...331975235?mt=8

Se gia' esiste questo, ci vuole poco a fare quello completo.

Forse tu, come altri, non vi rendete conto di una cosa: se Apple cambia, anche gli altri cambiano (come ho appena scritto sopra).
Windows 8 e' gia' su piattaforma ARM, ora anche Apple. Credi che Adobe e le altre aziende non si mettano a produrre software per ARM? Ma dai...

Gia' la mela di suo e' un bel trattore (ripeto: mio post sopra), se poi c'e' anche Windows... E contiamo che molte distro Linux gia' vanno su ARM, senza menzionare Android.

Non mi sembra che ci sia tutto sto casino che dici tu. Anzi, al contrario di quello che hai detto tu (che non ho quotato) e' Intel che si deve spaventare di ARM e non ARM che fara' fatica a spuntare fuori anche nei pc...

E pure AMD si deve spaventare, il doppio, non solo sul fronte CPU ma anche GPU visto che Nvidia e' gia' fuori con Tegra da mesi e mesi.



Se il mercato cambia, anche i professionisti si adeguano, altrimenti non "professano" piu' nulla, fidati.



Quello potrebbe anche succedere rimanendo su x86...



Quale sua CPU... Fino a poco fa i chip ARM degli iphone erano della Samsung... Apple non produce nulla di suo, se non il software. I componenti hardware sono fatti da altri (CPU intel e samsung, ssd intel o salcavolo, schede video nvidia, ecc). Lei ci mette software e design.

Semplicemente potrebbe passare a Tegra o Qualcomm, dov'e' il problema... Anzi, cerchera' di mantenere compatibilita' con quelli di iPhone e iPad in modo che una stessa app possa essere sviluppata per tutti i dispositivi con poche modifiche da fare (ovviamente senza dare la possibilita' che un'app per un iMac funzioni per iPhone, anche perche' su iMac hai tastiera e mouse...).

Apple è potente solo nel mercato in cui già ora domina, quello dei tablet/smartphone e dei lettori multimediali. Nel resto non vale una buccia di pera, basta vedere i dati di mercato. Può far diventare "magic" quel che vuole ma nel mercato professionale nessuno gli darà corda. Può solo sperare nel mercato consumer/semiprofessionale ma la vedo grigia pure lì con una mossa del genere.

Il fatto è che non può svegliarsi la mattina e dire da oggi ARM e sparare fuori tutta una nuova linea con CPU ARM. Per avere ìl software ci vorrà tempo. I big sicuramente lo faranno ma i piccoli sviluppatori potrebbero anche decidere di mandare a quel paese la mela e non aggiornare i propri sw. A parte questo, appena lanciata la nuova linea non si avrà niente da installarci sopra. O quasi nulla insomma, a parte le 4 applicazioncine Apple. Il ragionamento della gente sarà:

- Sanno della cosa e dicono "aspetto cosa fanno gli altri"
- Non lo sanno, comprano il PC, lo prendono nel e potrebbero decidere di abbandonare Apple al prossimo giro.

Questo nel mercato consumer. Nel mercato professionale dove già conta poco potrebbe perdere tutta una nuova linea di clienti.

E questo lato software. Lato HW ci sono molte sfide da vincere. Devono produrre una CPU ARM abbastanza potente da reggere OSX almeno alla stessa velocità con cui gira oggi su Core. La sfida è difficile, perchè servono risorse e conoscenze. Apple, che vuole disegnarsi la CPU in casa come quella di iPhone, non sarebbe in grado. Dovrebbe appoggiarsi a qualcuno:

- TI
- nVidia
- Qualcomm?

Al momento non sono competitivi contro Intel e penso non abbiano neanche interessi per investire nel ridicolo market share di OSX. Si parla di investimenti importanti e grossi rischi.

Apple deve aspettare i tempi degli altri e del mercato, questa volta non potrà fare lei il mercato, perchè non può permetterselo. E penso saranno Microsoft e Google/Linux a tirare questa volta.

ARM sta avendo un grosso impulso tirato dal mobile e nei giorni futuri ne vedremo delle belle ma: tempo al tempo! Intel con ARM perderà quote di mercato, ma non oggi e non con Apple.

Anche se qualcosa si sta muovendo, è di oggi la notizia dell'acquisizione di MIPS Tec da parte di Imagination Tec, quella che produce i SOC per Apple. Che Apple scelga MIPS? Se non altro il MIPS si sta preparando per un ritorno in grande stile, visti i risultati prestazionali che ha

[Baboo85]

Eh, ora parli di cose che non so

Architettura x86, Cell, ARM, CISC, RISC, MIPS... In questo campo mi limito a vedere i risultati finali (prestazioni, consumi, calore generato)


In ogni caso non vedo il cambiamento cosi' drammatico come dici tu. Contando che i nuovi pc Apple usciranno l'anno prossimo, in un anno di Windows 8 su ARM secondo me ne vedremo delle belle... E magari noi stiamo qui a dire di Apple, e tra 1 anno i pc saranno gia' ARM e non piu' x86

[jappilas]

Originariamente inviato da LMCH

Non a caso ho scritto "se AMD decidesse di applicare tutto il know how che ha in termini di capacità di sviluppare roba ad alte prestazioni e tirata al limite dell'inviluppo di potenza ...".
AMD non ARM ltd.

per sviluppare implementazioni non ARM della isa ARM mi risulta occorra una licenza architetturale
licenza che intel possedeva (ereditò da Digital e usò per sviluppare le cpu XScale - e poi vendette a Marvell se non erro - e probabilmente si sarà mangiata le mani...) ma che AMD non mi risulta possieda...

AMD ha il know-how necessario e le risorse per tirar fuori degli ARM ad alte prestazioni, non ARM ltd (che continua ad avere il suo core business come fornitore di IP, non come produttore/venditore di hardware).

...quindi questo è un discorso destinato a restare nell' ipotetico

Poi è vero che la parte decoder sulle cpu per desktop/server è "minima" rispetto al resto, ma non è così ininfluente come potrebbe sembrare a prima vista.

il decoder non è ininfluente, ma nemmeno così sostanziale...

a giudicare dal floorpan del K10 (in cui peraltro il - anzi i - decoder sono superscalari, quindi replicati a gruppi di 3, nonchè ulteriormente duplicati - per la decodifica nel caso normale e per quello in cui in cache non vi siano informazioni di tagging) molto più spazio del decoder prendono alu, strutture di esecuzione dinamica e riordino, eccetera

Pensa ad esempio al flop clamoroso di IA64 dovuto in primo luogo al suo set d'istruzioni ed a quello che implicava a cascata riguardo banda di I/O, decoder ed unità di esecuzione.

quello può essere stato un fattore, ma molto di più ha influito il fatto che intel abbia cercato di sostituire x86 con qualcosa di radicalmente diverso in un momento in cui il mondo informatico era ancora meno maturo di adesso per l'abbandono di X86,
motivo per cui venne messa una pezza integrando in Merced un vero e proprio subcore P6 (un pentium 2) dedicato alla retrocompatibilità
ma un sistema del genere aveva poco senso in partenza, se non come soluzione temporanea - infatti l' intenzione era di avere Itanium su tutti i nuovi sistemi da lì a qualche anno ...
solo, non si erano fatti i conti con le difficoltà inerenti al dover gestire esplicitamente da parte del programmatore il parallelismo delle istruzioni e l' allocazione dei registri, che se da un lato è necessaria per impiegare efficacemente l' architettura, è qualcosa non proprio alla portata di tutti o di tutte le occasioni d' impiego (anche per motivi di tempi), oltre che si è visto non essere la scelta ottimale con codice general purpose (dove l' hw di esecuzione speculativa può ottenere risultati molto migliori)
ma quando si cominciava a sfruttarla efficamente almeno per i calcoli scientifici, le cpu x86 avevano colmato il divario prestazionale e stavano a loro volta passando in vantaggio ...

Al massimo i primi ARM sono stati usati su home computer (e come potenza di calcolo erano più potenti dei corrispettivi x86 del periodo, usando pure meno gate sul chip) ma poi praticamente più niente in tal senso, al massimo PDA e smartphone, solo ora con tablet e smarphone sempre più potenti (e con la nuova architettura a 64bit) potrebbe iniziare l'attacco verso i desktop.

sì ma vedi in questo caso subentrano due tipi di problemi ... il primo prestazionale:
le istruzioni simd della isa ARMv8 prevedono calcoli su registri a 128 bit (peraltro condivisi con le istruzioni FP scalari), ma un Core che un' ipotetica cpu di classe ARM a 64 bit dovrebbe eguagliare (anzi superare, altrimenti non ci sarebbe alcun incentivo alla migrazione) possiede unità capaci di calcoli su 256 bit per volta (doppio di GFlOPS)
inoltre, trattandosi di una ISA RISC con istruzioni a lunghezza fissa di 32 bit, da una parte questo può implicare un decoder più semplice (se non altro perchè non è necessario fare un matching parallelo su tutti i 16 byte provenienti da una cache line - che potrebbero ognuno essere il primo di una differente istruzione a lunghezza variabile - nè decodificare tutti i prefissi prima dell' opcode vero e proprio)
ma comunque non è detto, dovendo il decoder fare comunque i conti con una varietà di modalità operative, come thumb/thumb2/thumbeee con i suoi opcode a 16 bit, e di indirizzamento - a meno che queste non vengano escluse...
e d' altra parte ha delle ricadute sulla code density e sul "lavoro utile" espresso in termini di quelle istruzioni
una cpu x86 moderna (k8 / K10 / core) integra 3 alu e 3 load/store più dei sommatori dedicati allo stack pointer e in certi casi altri sommatori a valle del decoder per pregenerare nel front end l' indirizzo dell' operando - quindi può eseguire fino a 6 operazioni (7 contando l' aggiornamento dell' SP in sideband), anche memoria - memoria, per ogni 3-4 istruzioni x86 (+1 condizionale che per un Core può essere fusa con un eventuale confronto, ottenendo un salto condizionato)
ma un' ipotetica CPU ARM di prestazioni paragonabili, quindi come minimo dotata di altrettante unità di calcolo (con annessa complessità), per tenerle alimentate costantemente avrebbe bisogno quantomeno di altrettante (6) istruzioni in ingresso, ma allora anche di cache line senz' altro più ampie e maggiore banda (anche come decode bandwidth) ma a quel punto il transistor count probabilmente non sarebbe più quello esiguo delle implementazioni arm in order non superscalari...
oltre al richiedere in certi casi più istruzioni a parità di lavoro (una load, un' operazione registro registro e una store piuttosto che una operazione memoria - memoria) come conseguenza intrinseca del tipo di architettura

in secundis, non sottovalutare l' importanza della retro- ed auto- compatibilità
tablet, smartphone ed altre appliance, nonchè in certo qual modo i centri di calcolo (accomunati dall' essere piattaforme principalmente "autocontenute" che si esauriscono in sè stesse, non influenzate dal sw che c'è stato prima e quel che verrà dopo) sono una cosa,
per una piattaforma usata nel "mondo reale" in cui la possibilità di usare sw attuale od anche di dieci- venti anni prima (basta vedere il PC, che solo adesso si sta "davvero" lasciando alle spalle il DOS, per supportare il quale il bios è stato mantenuto in vita finora) è un selling point, è assai diverso...

[birmarco]

Originariamente inviato da Baboo85

Eh, ora parli di cose che non so

Architettura x86, Cell, ARM, CISC, RISC, MIPS... In questo campo mi limito a vedere i risultati finali (prestazioni, consumi, calore generato)


In ogni caso non vedo il cambiamento cosi' drammatico come dici tu. Contando che i nuovi pc Apple usciranno l'anno prossimo, in un anno di Windows 8 su ARM secondo me ne vedremo delle belle... E magari noi stiamo qui a dire di Apple, e tra 1 anno i pc saranno gia' ARM e non piu' x86

Tutto il mercato in massa non credo Cmq sono curioso di vedere queste nuove soluzioni Quando i tempi saranno maturi un bel portatile ARM me lo faccio

[jappilas]

Originariamente inviato da Baboo85

Eh, ora parli di cose che non so

Architettura x86, Cell, ARM, CISC, RISC, MIPS... In questo campo mi limito a vedere i risultati finali (prestazioni, consumi, calore generato)

il problema è che se da appassionati ci si può soffermare sulle squisite caratteristiche tecniche delgi oggetti tecnologici in circolazione, in un' ottica generale fermarsi alla superficie non è sufficiente

In ogni caso non vedo il cambiamento cosi' drammatico come dici tu. Contando che i nuovi pc Apple usciranno l'anno prossimo, in un anno di Windows 8 su ARM secondo me ne vedremo delle belle... E magari noi stiamo qui a dire di Apple, e tra 1 anno i pc saranno gia' ARM e non piu' x86

sbagli prospettiva ...
una regola aurea da tenere sempre presente è che "una piattaforma è utile tanto quanto il sw che permette di far girare"
quindi se per delle piattaforme sostanzialmente autosufficienti e più o meno chiuse, è ancora ancora plausibile imporre che sia il sw a seguire l' hw (ma è necessario un notevole incentivo, reale oltre che percepito dagli utenti, perchè ciò avvenga - altrimenti si ottiene l' effetto opposto), per un PC o un Mac è l' opposto ...
prima viene il sw di cui ha bisogno l' utente (che sia un' applicazione di sviluppo, di progettazione, o un gioco), quindi dato il sw si cerca ciò su cui può girare finchè serve
già che la seconda regola aurea è che "uno strumento si cambia solo quando se ne pone la reale necessità" (quando non è più in grado di funzionare o quando un nuovo strumento apporta vantaggi quantificabilmente maggiori - come una produttività 10 volte maggiore a fronte di TOC non certo 10 volte maggiore)
e d' altra parte la base installata inficia le scelte di supporto (se il mercato mainstream è dominato da una certa architettura di cpu, è logico per quale mi convenga sviluppare)
quindi nel caso di una piattaforma retrocompatibile si innesca un circolo virtuoso e un andamento a "pipeline" (supporto per il sw legacy da parte di cpu correnti, per le quali nel frattempo si sviluppa e si distribuisce codice nativo, che a sua volta le cpu future - a meno di non essere più parte della stessa piattaforma - supporteranno)

se pensi che è grazie a questo che la piattaforma PC è sopravvissuta (/cresciuta) finora, e che per dire, solo adesso (che tutte le implementazioni x86 correnti supportano i 64 bit) ci si è (quasi) affrancati dal DOS e dal codice a 16 bit e i 32 sono il minimo sindacale (anche in quegli ambiti, tipicamente industriali, in cui il sw è installato una volta e lasciato a lavorare per anni o decenni) e se tirendi conto di quanto sia "enorme" nel suo complesso quella parte dell' IT in cui si fa uso di PC X86,
rompere la pipeline non conviene a nessuno...

Apple può avere interesse a farlo (per dissociarsi dalla massa - d' altra parte ha sempre sostenuto che i propri personal non fossero dei PC nemmeno col passaggio a x86 ) ma potrebbe non averne la possibilità (anche se la sua è una piattaforma sostanzialmente chiusa - integrata verticalmente - c'è comunque abbastanza codice di terze parti in circolazione da rendere l' operazione tutt' altro che indolore...)

[Cfranco]

Originariamente inviato da LMCH

Ai tempi che furono l'ARM2 realizzato con un quarto dei transitor dell'80286 gli spaccava il cuBo a colpi di pura potenza di calcolo.

Originariamente inviato da birmarco

Sarà anche un'architettura inefficiente e obesa (Atom ne è uno degli ultimi esempi)

Ocio che l' "architettura" non vuol dire niente, il 286 era una cpu cisc che elaborava un' operazione alla volta, non esisteva un decoder vero e proprio ma era la cpu stessa a costituirlo, non aveva pipeline e ci metteva da 2 a 10 ( o anche di più ) cicli di clock per elaborare un' istruzione, sempre che non dovesse accedere alla ram perchè allora i cicli wait di attesa fioccavano ...
Il primo arm fece scalpore perchè lanciò il concetto di cpu risc, grazie alla pipeline elaborava un' istruzione per ciclo di clock ( almeno in condizioni ideali ) suddividendola in passi stile catena di montaggio, quella è l' innovazione fondamentale, l' instruction set ridotto era solo una conseguenza.
L' attuale struttura delle cpu arm, Intel e AMD è una base risc a cui sono state apportati parecchi miglioramenti per tenere la pipeline sempre piena ( branch predictor, cache sempre più generose, esecuzioni out-of-order ... etc ), e intanto paradossalmente l' ISA dei risc è aumentato esponenzialmente per includervi operazioni sempre più complesse ( le varie SSE per ia-64 ma anche ARM ha aggiunto ThumbEE, Neon e altra roba ) cosicchè al giorno d' oggi le due architetture sono largamente sovrapponibili: una ISA di tipo CISC con un motore RISC agli steroidi.
Paradossalmente si potrebbe prendere una CPU qualsiasi, cambiargli il decoder e fargli elaborare una ISA diversa con relativamente pochi adattamenti.

Originariamente inviato da LMCH

Stai facendo troppa confusione tra architetture di cpu ed aziende.

Non a caso ho scritto "se AMD decidesse di applicare tutto il know how che ha in termini di capacità di sviluppare roba ad alte prestazioni e tirata al limite dell'inviluppo di potenza ...".
AMD non ARM ltd.

Ops
Cmq anche AMD è un nanetto confronto a Intel
I problemi che ha attualmente derivano proprio da questo, ha troppi pochi soldi per competere ...

Originariamente inviato da LMCH

Poi è vero che la parte decoder sulle cpu per desktop/server è "minima" rispetto al resto, ma non è così ininfluente come potrebbe sembrare a prima vista.

Pensa ad esempio al flop clamoroso di IA64 dovuto in primo luogo al suo set d'istruzioni ed a quello che implicava a cascata riguardo banda di I/O, decoder ed unità di esecuzione.
Nonostante Intel ci si sia svenata dietro in tutti i modi ormai sopravvive solo grazie al contratto capestro di HP che impone ad Intel di continuare a supportare tale cpu.
Ed infatti dopo quella batosta Intel se ne è uscita con la sua attuale strategia "x86 ovunque".

Il problema fondamentale dell' Itanium è che non è compatibile x86 e quindi non gliene frega niente a nessuno
Il discorso decoder per i processori VLIW è molto complesso, un decoder CISC trasforma facilmente le istruzioni in un subset RISC cosicchè le due soluzioni siano equivalenti, un' istruzione complessa può facilmente essere spezzettata e il parallelismo resta gestito dal processore, i VLIW hanno un approccio diverso, il parallelismo esplicito influenza direttamente il compilatore e il modo in cui i programmi dovrebbero essere scritti, peccato che i linguaggi di programmazione più usati e gli algoritmi siano sequenziali, c' è un lavorone da fare per parallelizzare il tutto, e chi ci si mette a farlo ?

[birmarco]

Originariamente inviato da Cfranco

Ocio che l' "architettura" non vuol dire niente, il 286 era una cpu cisc che elaborava un' operazione alla volta, non esisteva un decoder vero e proprio ma era la cpu stessa a costituirlo, non aveva pipeline e ci metteva da 2 a 10 ( o anche di più ) cicli di clock per elaborare un' istruzione, sempre che non dovesse accedere alla ram perchè allora i cicli wait di attesa fioccavano ...
Il primo arm fece scalpore perchè lanciò il concetto di cpu risc, grazie alla pipeline elaborava un' istruzione per ciclo di clock ( almeno in condizioni ideali ) suddividendola in passi stile catena di montaggio, quella è l' innovazione fondamentale, l' instruction set ridotto era solo una conseguenza.
L' attuale struttura delle cpu arm, Intel e AMD è una base risc a cui sono state apportati parecchi miglioramenti per tenere la pipeline sempre piena ( branch predictor, cache sempre più generose, esecuzioni out-of-order ... etc ), e intanto paradossalmente l' ISA dei risc è aumentato esponenzialmente per includervi operazioni sempre più complesse ( le varie SSE per ia-64 ma anche ARM ha aggiunto ThumbEE, Neon e altra roba ) cosicchè al giorno d' oggi le due architetture sono largamente sovrapponibili: una ISA di tipo CISC con un motore RISC agli steroidi.
Paradossalmente si potrebbe prendere una CPU qualsiasi, cambiargli il decoder e fargli elaborare una ISA diversa con relativamente pochi adattamenti.

Io ho sempre saputo che x86 è CISC e non RISC, mentre ARM è CISC. Però potrebbero aver sì aumentato l'ISA fino a diventare CISC. Però allora non si può più parlare di RISC, visto che esiste la definizione CISC apposta O sbaglio?

Se dovessimo fare un raffronto non sarebbe sempre più CISC un'architettura x86 attuale (grazie per la correzione, effettivamente non ci avevo pensato ) che una ARM attuale, no? Altrimenti tutte le differenze andrebbero a farsi benedire e ARM sarebbe tanto diverso da x86 come AMD è diverso da Intel. Se cambiasse solo l'implementazione e 2 o 3 ISA andrebbero diversamente solo a seconda del tipo di implementazione e quindi non ci sarebbero fondamentalmente differenze per preferire un'arch dall'altra se non in base al modello della CPU.

PS. Non sono pienamente d'accordo sul fatto che l'HW si deve adeguare al SW. Attualmente mi sembra più ragionevole un compromesso che tiene sempre conto di prestazioni, difficoltà di realizzazione e costi. Se devo fare un SW che deve fare sempre operazioni di somma su array da 10000 valori (per assurdo), non creo un set di istruzioni apposito nella CPU, sarò io programmatore che userò (sempre per assurdo) diverse concatenazioni di array da 100 valori per mandarli in esecuzione 100 e 100.

[jappilas]

Originariamente inviato da birmarco

Io ho sempre saputo che x86 è CISC e non RISC, mentre ARM è CISC.

anche se leggendo la frase probabilmente è quello che intendevi dire
la architettura ARM è RISC

Però potrebbero aver sì aumentato l'ISA fino a diventare CISC.

aumentare l' isa aggiungendo istruzioni farebbe magari crescere le dimensioni della tabella degli opcode, e magari richiederebbe di ricorrere al microcodice non bastando pià la logica cablata per il decoder...
ma non farebbe diventare CISC una cpu nata RISC, perchè non verrebbero meno caratteristiche inerenti e distintive di un' architettura RISC:
istruzioni con opcode della stessa lunghezza (piuttosto che di lunghezza variabile)
istruzioni distinte per tipo, con load /store dedicate ai trasferimenti registri <-> memoria - e logiche operanti solo su registri (piuttosto che istruzioni con operandi indifferentemente registro o memoria)
operazioni su registri non distruttive (a=b+c, piuttosto che a=a+b),
registri general purpose in numero consistente (piuttosto che limitato)

Però allora non si può più parlare di RISC, visto che esiste la definizione CISC apposta O sbaglio?

da una parte si può tenere presente che RISC e CISC sono definizioni nate a posteriori (dopo che a berkeley e stanford si pensò di progettare processori architetturalmente semplici e ortogonali basati sulla constatazione che l' 80% delle istruzioni eseguite ricadevano in un sottoinsieme semplice di quelle supportate dai sistemi esistenti)
dall' altra "CISC" o "RISC" è un' etichetta che si dà alla ISA visibile dal programmatore/compilatore e solo a quella - che l' implementazione adotti "tecniche risc" quali la segmentazione di istruzioni cisc in operazioni primitive che consentano di regolarizzare la pipeline, non rende un X86 RISC
( peraltro a ben vedere le moderne cpu x86 hanno invertito la tendenza... K6 e P6 in fase di decodifica producevano sequenze di microistruzioni "risc-like", immesse in pipeline e schedulate ognuna a parte, ma le macroops delle cpu Athlon e le "fused micro-op" dei Core e degli Atom - aggregati di operazioni elementari schedulati come entità unica e spezzati per l' invio alle unità esecutive all' ultimo - sono tutto meno che primitive, quindi RISC... )
quidni non sbagli

[birmarco]

Originariamente inviato da jappilas

anche se leggendo la frase probabilmente è quello che intendevi dire
la architettura ARM è RISC

Esatto A scrivere CISC e RISC ogni 3 parole si mischiamo

aumentare l' isa aggiungendo istruzioni farebbe magari crescere le dimensioni della tabella degli opcode, e magari richiederebbe di ricorrere al microcodice non bastando pià la logica cablata per il decoder...
ma non farebbe diventare CISC una cpu nata RISC, perchè non verrebbero meno caratteristiche inerenti e distintive di un' architettura RISC:
istruzioni con opcode della stessa lunghezza (piuttosto che di lunghezza variabile)
istruzioni distinte per tipo, con load /store dedicate ai trasferimenti registri <-> memoria - e logiche operanti solo su registri (piuttosto che istruzioni con operandi indifferentemente registro o memoria)
operazioni su registri non distruttive (a=b+c, piuttosto che a=a+b),
registri general purpose in numero consistente (piuttosto che limitato)
da una parte si può tenere presente che RISC e CISC sono definizioni nate a posteriori (dopo che a berkeley e stanford si pensò di progettare processori architetturalmente semplici e ortogonali basati sulla constatazione che l' 80% delle istruzioni eseguite ricadevano in un sottoinsieme semplice di quelle supportate dai sistemi esistenti)
dall' altra "CISC" o "RISC" è un' etichetta che si dà alla ISA visibile dal programmatore/compilatore e solo a quella - che l' implementazione adotti "tecniche risc" quali la segmentazione di istruzioni cisc in operazioni primitive che consentano di regolarizzare la pipeline, non rende un X86 RISC
( peraltro a ben vedere le moderne cpu x86 hanno invertito la tendenza... K6 e P6 in fase di decodifica producevano sequenze di microistruzioni "risc-like", immesse in pipeline e schedulate ognuna a parte, ma le macroops delle cpu Athlon e le "fused micro-op" dei Core e degli Atom - aggregati di operazioni elementari schedulati come entità unica e spezzati per l' invio alle unità esecutive all' ultimo - sono tutto meno che primitive, quindi RISC... )
quidni non sbagli

Be ma quindi alla fine non si può cmq dire che le due architetture convergano, che è anche il punto iniziale del discorso Alla fine quel che fa RISC efficiente rimane caratteristica RISC e per CISC stesso ma opposto discorso Cmq mi chiedo sempre perchè Intel abbia scelto CISC, a me sembra sempre meglio una RISC "espansa" tranne che per cose di nicchia In fondo, come si disse a Barkley (quella storiella me l'ero dimenticata ) la CISC fa tutto sto casino per il 20% di sitruzioni, dove magari c'è un'altro sotogruppo magari del 15% facilmente implementabile RISC per cui per fare una piccola parte delle operazioni si complica di brutto l'architettura, e si rallenta. Visto che si complicano pipeline, parallelismo, registri ecc...

PS. Ma le micro-op non sono precedenti agli Atom?

[LMCH]

Originariamente inviato da Cfranco

Il problema fondamentale dell' Itanium è che non è compatibile x86 e quindi non gliene frega niente a nessuno

La compatibilità x86 non era un problema, a parte questo i primi Itanium (pensati per competere con server non-x86) avevano per precauzione (non per vera necessità) l'equivalente di un decoder 486 integrato nel chip (nel senso che supportava le istruzioni 486, non che avesse le prestazioni di un 486) ma nei successivi fu tolto perchè l'emulazione via software dava maggiori prestazioni e perchè serviva principalmente per il boot da cd con bootloader x86 di dischi di installazione con versioni "doppie" del S.O. (per x86 e per Itanium)

Il vero problema erano le prestazioni.

L'idea era che gli Itanium prima avessero preso la fascia alta (occupata in quel periodo dai RISC) e poi sarebbero diventati i successori degli x86 man mano che i 32bit sarebbero diventati strettini (anche per quel motivo Intel non aveva fretta di uscire con una sua versione a 64bit degli x86).
Microsoft si era già impegnata a portare Windows su Itanium e se non sbaglio stava già lavorando dietro le quinte su .Net

Itanium doveva spazzar via i RISC nei server di fascia medio-alta di quel periodo (i POWER, i MIPS64 di SGI, i Prism di HP, gli Alpha ex-DEC di COmpaq, gli Sparc, ecc.).
Spazzar via i Prism non era un problema a prescindere perchè Itanium fu inizialmente sviluppato a braccetto con HP proprio come successore dei Prism.
Compaq stava per essere acquisita da HP ed una delle precondizioni era che la morte programamta degli Alpha avvenisse pianificata prima dell'acquisizione in modo da non innervosire l'antitrust.
Vista l'aria che tirava (Intel che diceva a tutti che avrebbe investito tantissimo su Itanium per farlo diventare l'architettura standard a 64bit per i server per poi più avanti sostituire magari pure gli x86) SGI annunciò a sua volta che sarebbe passata ad Itanium.
Pure IBM annuncio che avrebbe realizzato dei server basati su Itanium (ma avrebbe amntenuto anche la sua linea POWER).

Insomma, Intel sembrava che avesse già vinto su tutta la linea (eccetto per Sun con i suoi Sparc ed UltraSparc) e dovesse uscire sul mercato con la suo nuova cpu.

Solo che quando iniziarono ad essere disponibili i primi benchmark dell'Itanium scoppiò a dir poco un merdone: la prima generazione non saliva di clock come la concorrenza, aveva buone prestazioni floating point ma faceva pena per quel che riguarda gli interi, richiedeva chip enormi e scaldava a bestia (anche rispetto a chip che era normale fossero belli "caldi").

Le cpu Alpha (già con data morte programmata e che erano almeno tre anni che al massimo veniva shrinkate) erano più veloci nelle applicazioni reali e pure gli x86-64 di AMD (perchè Intel non aveva ancora x86 a 64bit) a parità di costo fornivano prestazioni interessanti.

Fu un disastro, ed anche le versioni successive degli Itanium non sono riuscite a salire di clock come la concorrenza (es: i POWER vanno tranquillamente a più di 5GHz di clock) ... inclusa la concorrenza "interna" costituita dagli x86 di Intel stessa.

Per rendere l'idea, la cpu Itanium più recente (Tukwila) raggiunge al massimo 1.73GHz.

[LMCH]

Originariamente inviato da birmarco

Secondo me quello che dici è giusto ma non considera una cosa fondamentale: la ricchezza di Intel. Intel è un'azienda che ha dalla sua fondi, fabbriche e know-how necessari per sviluppare al massimo x86. Sarà anche un'architettura inefficiente e obesa (Atom ne è uno degli ultimi esempi) ma riesce a garantire un buon livello di potenza, e con quei tre elementi di poco fa Intel ci metterebbe poco a farla spingere al massimo. A suon di riduzioni di PP la fanno sembrare sempre più efficiente, e di fatto quello che conta è il consumo effettivo.

ARM può sperare con AMD ma non sarebbe in grado di competere per un ingresso di punta nel mercato, non ha le risorse necessarie. In più dovrebbero appoggiarsi a TMSC (che ultimamente non brilla) e Globalfoundries, ma le rese produttive potrebbero non essere sufficienti.

Ad Intel la ricchezza ed il know-how potrebbero non bastare, con gli ARM non ha un unico concorrente, ma tanti, con obiettivi e priorità diverse e non può contrastarli tutti simultaneamente.
AMD è solo il soggetto con maggiori possibilità (per mezzi e know-how) di uscire con un ARM "da server ad alte prestazioni", ma non è l'unico.

Anche senza cercare lo scontro diretto con Intel, le prestazioni dei core ARM stanno aumentando anche solo per il semplice passaggio alla tecnologia produttiva successiva.
Ad un certo punto gli ARM saranno abbastanza potenti e costeranno in rapporto molto meno ed a quel punto ...