Snapdragon 1000: fino a 12 W per competere con Intel tramite Windows on ARM

[Redazione di Hardware Upg]

Link alla notizia: https://www.hwupgrade.it/news/cpu/sn...arm_76731.html

Qualcomm sarebbe al lavoro su un nuovo processore dedicato al mondo Windows on ARM: lo Snapdragon 1000, le cui caratteristiche termiche lasciano presagire prestazioni superiori agli attuali chip del produttore

Click sul link per visualizzare la notizia.

[supertigrotto]

Architettura Arm é superiore alla architettura x86 finché le istruzioni in gioco e la mole di calcoli in gioco sono semplici,allo scalare della complessità mica é tanto più efficiente della controparte,a sto punto era meglio rispolverare MIPS che a livello di efficienza,anche nello scalare,si è dimostrata migliore di Arm e l'unica in grado di impensierire l'architettura x86,idem per la architettura Power

[nickname88]

Poveretti
Ma su desktop e workstation non s'ha da fare ....

[csavoi]

Tutto dipende dal supporto software della nuova architettura.
Anche se MIPS e POWER hanno le carte più che in regola per essere più performanti delle soluzioni X86 e ARM, lato software sono carenti e quindi non ci si investirà mai sopra.

Viceversa ARM può contare sull'enorme sviluppo e diffusione dei software sui telefonini Android che, con ogni probabilità, potrebbero essere portati su ARM/Windows con più semplicità.

Cmq, spezzare il monopolio X86 può fare bene purchè ARM sia veramente competitiva, per attrarre nuovi sviluppatori e nuovi OEM deve avere un vantaggio del 30%-40% su INTEL/AMD in generale (ossia più prestazioni e minor costi progettuali e di silicio)

[Yrbaf]

Adesso si usa ARM64 e tale ISA diversamente da ARM32 è molto Mips-like.

[LMCH]

Originariamente inviato da supertigrotto

Architettura Arm é superiore alla architettura x86 finché le istruzioni in gioco e la mole di calcoli in gioco sono semplici,allo scalare della complessità mica é tanto più efficiente della controparte,a sto punto era meglio rispolverare MIPS che a livello di efficienza,anche nello scalare,si è dimostrata migliore di Arm e l'unica in grado di impensierire l'architettura x86,idem per la architettura Power

Come ha detto pure @Yrbaf l'architettura ARM64 (ARMv8 e successive evoluzioni) non a caso è molto simile a quella delle cpu MIPS ed (aggiungo io) a quella delle cpu Alpha di DEC (il top a livello di cpu a 64bit in termini di prestazioni per anni ed anni fintantoché DEC ha continuato ad investirci sopra una frazione di quello che spendeva Intel nello sviluppo degli x86).

Notare anche che qui si parla di un SoC che consuma max 12W con un area che è circa 1/4 di un core i5 U da 15W.
Se ottiene prestazioni decenti già così, a parità di area e di consumi di core+cache sono prevedibili caXXi amari per Intel.

Praticamente a quel punto la sopravvivenza di Intel dipenderebbe esclusivamente dalla retrocompatibilità con le vecchie applicazioni win32 e .Net che per un motivo o l'altro possono girare solo su cpu x86.
Non è un bel scenario considerando che Microsoft stessa sta spingendo il più possibile su UWP e verso l'abbandono di win32.

[imayoda]

un altro processore per refreshare facebook,
ci sarà da ridere quando e se si passerà ad arm per programmi della suite adobe, autodesk etc.

[tuttodigitale]

Originariamente inviato da LMCH

Notare anche che qui si parla di un SoC che consuma max 12W con un area che è circa 1/4 di un core i5 U da 15W.

le dimensioni di 45x24mm si riferiscono al package di Cannon Lake che contiene oltre la CPU/GPU anche il chipset.
Le mggiori dimensioni del package sono dovute alla necessità di avere un numero molto alto di pin per la maggior dotazione di risorse, basti pensare alla possibilità di avere una GPU discreta.
Grazie tante se il package è più piccolo....

le dimensioni del die di uno snapdragon 835 è di 73,5mmq poco più di quello di CL (71mmq), e poco meno di quello skylake (82mmq).
Ci vuole un miracolo per ridurre le dimensioni a meno di 20mmq....

[LMCH]

Originariamente inviato da tuttodigitale

le dimensioni di 45x24mm si riferiscono al package di Cannon Lake che contiene oltre la CPU/GPU anche il chipset.
Le mggiori dimensioni del package sono dovute alla necessità di avere un numero molto alto di pin per la maggior dotazione di risorse, basti pensare alla possibilità di avere una GPU discreta.
Grazie tante se il package è più piccolo....

le dimensioni del die di uno snapdragon 835 è di 73,5mmq poco più di quello di CL (71mmq), e poco meno di quello skylake (82mmq).
Ci vuole un miracolo per ridurre le dimensioni a meno di 20mmq....

Capisco. Nell'articolo la cosa non era chiara.
Resta comunque un chippetto a cui Intel può solo contrapporre la retrocompatibilità con il software x86 legacy.

[s-y]

non sono aggiornato, e non è strettamente a tema, anche se decisamente collegato
come lo stato dell'arte riguardo alla questione della 'emulazione' delle chiamate x86 tramite arm e relativa 'dichiarazione di guerra' legale da parte di intel?

[cdimauro]

Originariamente inviato da LMCH

Capisco. Nell'articolo la cosa non era chiara.
Resta comunque un chippetto a cui Intel può solo contrapporre la retrocompatibilità con il software x86 legacy.

Ma anche no: vedi le prestazioni. x86/x64 hanno ottime prestazioni in single core/thread, nonostante siano un'architettura CISC abbastanza complicata (ARMv8/ARM64 ha il vantaggio di essere stata completamente riprogettata).

Questo perché un'architettura CISC (come quella) ha comunque la possibilità di poter eseguire più "lavoro utile". Ad esempio è il motivo per cui i primissimi Atom, nonostante fossero in-order (a 2 vie), arrivavano a competere coi Cortex-A15, che erano out-of-order a 3 vie, pur con un processo produttivo penoso (e consumavano pure molto meno).

Inoltre x86/x64 hanno unità SIMD più potenti rispetto a qualunque ARM (attuale; almeno finché non arriverà la nuova unità vettoriale che ARM ha presentato un paio d'anni fa, ma dovremo vedere come si comporterà sul campo), e CannonLake poi si porta dietro la nuovissima AVX-512, che è un autentico gioiello (oltre a consumare un sacco di spazio su chip, coi suoi 32 registri a 512 bit, e annesse unità di calcolo a 512 bit. Ecco perché c'è tutta quella differenza di dimensione).

Checché se ne dica, x86/x64 possono ancora dire la loro.

/OT

[tuttodigitale]

Originariamente inviato da cdimauro

Ma anche no: vedi le prestazioni. x86/x64 hanno ottime prestazioni in single core/thread, nonostante siano un'architettura CISC abbastanza complicata (ARMv8/ARM64 ha il vantaggio di essere stata completamente riprogettata).

Questo perché un'architettura CISC (come quella) ha comunque la possibilità di poter eseguire più "lavoro utile". Ad esempio è il motivo per cui i primissimi Atom, nonostante fossero in-order (a 2 vie), arrivavano a competere coi Cortex-A15, che erano out-of-order a 3 vie, pur con un processo produttivo penoso (e consumavano pure molto meno).

Inoltre x86/x64 hanno unità SIMD più potenti rispetto a qualunque ARM (attuale; almeno finché non arriverà la nuova unità vettoriale che ARM ha presentato un paio d'anni fa, ma dovremo vedere come si comporterà sul campo), e CannonLake poi si porta dietro la nuovissima AVX-512, che è un autentico gioiello (oltre a consumare un sacco di spazio su chip, coi suoi 32 registri a 512 bit, e annesse unità di calcolo a 512 bit. Ecco perché c'è tutta quella differenza di dimensione).

Checché se ne dica, x86/x64 possono ancora dire la loro.

/OT

la differenza la fanno anche le ottimizzazioni....il fatto di contrapporre ad un ASICs ad un chip custom dà al mondo X86 un vantaggio tale ad alta frequenza da annullare qualsiasi penalità dovuta alla maggior complessità della logica x86.

[cdimauro]

I più grandi produttori di chip ARM (Qualcomm, Samsung, Huawei, Apple) utilizzano soluzioni custom, infatti.

[yankeeone]

Chi dice che lo Snapdragon 1000 é solo una cpu (e lo confronta solo con il DIE della cpu Inte) si sbaglia, lo snapdragon 1000 é un SOC dotato di cores, memory controller, chipset, controller di archiviazione, gpu (adreno) e modem 5G.
Il TDP é relativo a tutto il SOC (GPU, MMC, MODEM) perciò il confronto delle aree scritto sull'articolo é corretto.
Sarà una bella bestiolina.
Peccato che per problemi di licenze (grazie Intel) non possano emulare x86_64 ma solo x86.

[cdimauro]

E' AMD ad avere inventato x86_64/x64, e non Intel. Intel ha inventato IA-32/x86 (sul quale x64 è basato). Intel e AMD hanno un accordo di cross-licensing. Quindi, eccezion fatta per la parte ereditata da x86, di x64 dovrebbe essere AMD a occuparsene, e non Intel.

Anche le CPU di Intel, per il restom sono sostanzialmente dei SoC, visto che incorporano anche loro non soltanto i core veri e propri, ma nel cosiddetto "uncore" annoverano anche controller della memoria, del PCI-Express, GPU, e altra roba.

Manca il modem 5G, in effetti, ma del resto non sappiamo esattamente cosa ci sia in entrambi i SoC (ad esempio il controller PCI-Express occupa anch'esso spazio nei SoC Intel, che mettono a disposizione numerose linee a riguardo).

In ogni caso la notizia non riporta esattamente la dimensione dei core di entrambi i SoC.

Ricordo soltanto che tempo fa erano state riportate delle immagini con annesse dimensioni dei soli core, e quelli di Intel erano sì più grandi, ma non molto rispetto a quelli ARM (di Apple, che sono quelli che offrono prestazioni più elevate) con cui erano confrontati.

[LMCH]

Originariamente inviato da cdimauro

Ma anche no: vedi le prestazioni. x86/x64 hanno ottime prestazioni in single core/thread, nonostante siano un'architettura CISC abbastanza complicata (ARMv8/ARM64 ha il vantaggio di essere stata completamente riprogettata).

Questo perché un'architettura CISC (come quella) ha comunque la possibilità di poter eseguire più "lavoro utile". Ad esempio è il motivo per cui i primissimi Atom, nonostante fossero in-order (a 2 vie), arrivavano a competere coi Cortex-A15, che erano out-of-order a 3 vie, pur con un processo produttivo penoso (e consumavano pure molto meno).

Inoltre x86/x64 hanno unità SIMD più potenti rispetto a qualunque ARM (attuale; almeno finché non arriverà la nuova unità vettoriale che ARM ha presentato un paio d'anni fa, ma dovremo vedere come si comporterà sul campo), e CannonLake poi si porta dietro la nuovissima AVX-512, che è un autentico gioiello (oltre a consumare un sacco di spazio su chip, coi suoi 32 registri a 512 bit, e annesse unità di calcolo a 512 bit. Ecco perché c'è tutta quella differenza di dimensione).

Checché se ne dica, x86/x64 possono ancora dire la loro.

/OT

A15 era un ARMv7 (32 bit con set d'istruzioni limitato dai flag di esecuzione condizionale, per quel che riguarda l'esecuzione out-of-order) era progettato per essere un ARM "più potente" (sempre restando nell'ambito mobile del periodo) e per quel che riguardava i consumi, gli Atom andavano a scontrarsi anche con i SoC basati su A7 e li le prendevano di brutto sotto quell'aspetto.
In Intel pensavano di contrapporre una singola linea di SoC contro una serie di linee distinte di SoC compatibili a livello di applicazioni tra loro ma che privilegiavano di volta in volta caratteristiche differenti e si è visto come è andata a finire.
Gli x86/64 possono ancora dire la loro, ma ora i produttori di chip ARM stanno iniziando a prendere di mira settori dominati da x86/64 ed Intel non sembra avere una strategia migliore se non sperare che la retrocompatibilità con le applicazioni x86 sia una feature ancora irrinunciabile in quei settori.

[cdimauro]

Originariamente inviato da LMCH

A15 era un ARMv7 (32 bit con set d'istruzioni limitato dai flag di esecuzione condizionale, per quel che riguarda l'esecuzione out-of-order) era progettato per essere un ARM "più potente" (sempre restando nell'ambito mobile del periodo) e per quel che riguardava i consumi, gli Atom andavano a scontrarsi anche con i SoC basati su A7 e li le prendevano di brutto sotto quell'aspetto.

Ma venivano polverizzati lato prestazionale, incluso l'A9 (l'A7 non c'era ancora all'epoca di quei test) che era parzialmente out-of-order.

Sì, erano ARMv7 a 32 bit, ma gli Atom erano x86 e non x64 (quindi col classico set d'istruzioni nato con gli 80386: appena 8 registri in totale, e quindi facendo uno spasmodico uso dello stack per le variabili temporanee. ARMv7, per contro, offriva 16 registri, esecuzione condizionale, e istruzioni a 3 operandi: vedi tu che differenza c'era).

Ne abbiamo già parlato in passato, e avevo anche riportato un articolo di Extremetech che analizzava questi processori sia dal punto di vista prestazionale sia dei consumi: The final ISA showdown: Is ARM, x86, or MIPS intrinsically more power efficient?

In Intel pensavano di contrapporre una singola linea di SoC contro una serie di linee distinte di SoC compatibili a livello di applicazioni tra loro ma che privilegiavano di volta in volta caratteristiche differenti e si è visto come è andata a finire.

Sì, ma è andata finire così anche perché su mobile è accaduto, e accade, quello che specularmente è successo e succede su desktop: ARM s'è presa il mercato, ed è diventata dominante. Per cui Intel, come pure altri produttori di processori (IBM/Freescale & co. con PowerPC; Infineon con MIPS) che hanno provato a entrarci, è rimasta fuori nonostante gli enormi investimenti e i buoni prodotti (a mio avviso è stato stupido abbandonare proprio quando ormai aveva un prodotto, ApolloLake, molto competitivo anche lato consumi).

Il legacy. La retro/compatibilità.

Solita questione, insomma.

Gli x86/64 possono ancora dire la loro, ma ora i produttori di chip ARM stanno iniziando a prendere di mira settori dominati da x86/64 ed Intel non sembra avere una strategia migliore se non sperare che la retrocompatibilità con le applicazioni x86 sia una feature ancora irrinunciabile in quei settori.

Vedi sopra. Lato server, dove si sente di gran lunga mano la questione legacy, sono anni che ci provano, ma non sono riusciti a entrare lo stesso, tanto che qualche mese fa c'erano voci che circolavano e che dicevano che Qualcomm starebbe valutando di rinunciare al mercato server dopo tutti gli investimenti che ha fatto.

Evidentemente non è solo questione di legacy.

[LMCH]

Originariamente inviato da cdimauro

Ma venivano polverizzati lato prestazionale, incluso l'A9 (l'A7 non c'era ancora all'epoca di quei test) che era parzialmente out-of-order.

Giusto, ma era il lato costo + consumi ad essere più rilevante in fascia bassa e li non c'era storia.

Originariamente inviato da cdimauro

Ne abbiamo già parlato in passato, e avevo anche riportato un articolo di Extremetech che analizzava questi processori sia dal punto di vista prestazionale sia dei consumi: The final ISA showdown: Is ARM, x86, or MIPS intrinsically more power efficient?

Quello è un confronto che usa benchmark "classici" e non casi d'uso tipici dei dispositivi tipo smartphone e tablet, dove le cpu non girano a lungo a pieno carico (e dove l'efficienza energetica a pieno carico è meno rilevante).

Originariamente inviato da cdimauro

Sì, ma è andata finire così anche perché su mobile è accaduto, e accade, quello che specularmente è successo e succede su desktop: ARM s'è presa il mercato, ed è diventata dominante. Per cui Intel, come pure altri produttori di processori (IBM/Freescale & co. con PowerPC; Infineon con MIPS) che hanno provato a entrarci, è rimasta fuori nonostante gli enormi investimenti e i buoni prodotti (a mio avviso è stato stupido abbandonare proprio quando ormai aveva un prodotto, ApolloLake, molto competitivo anche lato consumi).

Il legacy. La retro/compatibilità.

Solita questione, insomma.

Vuoi dire che il maggior consumo di batteria nei casi d'uso reali non era un problema?
La retrocompatibilità non era un problema, ti sto scrivendo con un tablet android con cpu x86 e non ho mai avuto problemi legati ad app che non girano su x86, nonostante Intel abbia mollato tablet e smartphone da anni.
Questo tablet l'ho preso per il display da 12", si noti bene, non per il tipo di cpu che ha (a cui è abbinata una batteria da 12000mAh, si noti bene)

Originariamente inviato da cdimauro

Vedi sopra. Lato server, dove si sente di gran lunga mano la questione legacy, sono anni che ci provano, ma non sono riusciti a entrare lo stesso, tanto che qualche mese fa c'erano voci che circolavano e che dicevano che Qualcomm starebbe valutando di rinunciare al mercato server dopo tutti gli investimenti che ha fatto.

Evidentemente non è solo questione di legacy.

Anche lato server esistono il lato legacy e le economie di scala a ivello di manutenzione e supporto del parco hardware e software installato ha il suo bel peso pure li.

[cdimauro]

Originariamente inviato da LMCH

Giusto, ma era il lato costo + consumi ad essere più rilevante in fascia bassa e li non c'era storia.

All'epoca a Intel non interessava quella fascia bassa.

I primi Atom, come già detto, erano in-order a 2 vie: per fare "di meno" Intel avrebbe dovuto rispolverare il design del 486 o addirittura del 386. Cosa che ha fatto un po' di anni dopo con la famiglia Quark.

Quello è un confronto che usa benchmark "classici" e non casi d'uso tipici dei dispositivi tipo smartphone e tablet, dove le cpu non girano a lungo a pieno carico (e dove l'efficienza energetica a pieno carico è meno rilevante).

Permettimi: si parlava (anche tu l'hai fatto) di prestazioni, e quindi quei test erano perfettamente pertinenti.

Vuoi dire che il maggior consumo di batteria nei casi d'uso reali non era un problema?

Lo era, certamente, ma per altri motivi.

Primo, Intel non usava (e non usa ancora) processi low-power.

Secondo, Intel non aveva nulla di simile al big.little, che è nato apposta per ridurre i consumi.

Per il terzo vedi sotto.

La retrocompatibilità non era un problema, ti sto scrivendo con un tablet android con cpu x86 e non ho mai avuto problemi legati ad app che non girano su x86, nonostante Intel abbia mollato tablet e smartphone da anni.
Questo tablet l'ho preso per il display da 12", si noti bene, non per il tipo di cpu che ha (a cui è abbinata una batteria da 12000mAh, si noti bene)

La retrocompatibilità, invece, era un problema, perché la stragrande maggioranza dei binari (mi riferisco alle app che usano l'NDK qui. Non a quelle Java, che ovviamente non hanno di queste problematiche) che scaricavi/chi dal Playstore sono ARM, e Intel ha dovuto mettere in piedi un emulatore allo scopo (si chiama Houdini), che purtroppo è tutt'altro che perfetto, oltre a richiedere costante manutenzione (causa nuove API di Android e/o nuove app che non funzionano bene con la versione attuale e necessitano di apposite patch).

Questo ovviamente va incidere, e pure molto, sulla batteria, visto che non soltanto il gioco (perché in realtà sono quasi tutti giochi le app che usano NDK, e che quindi sono CPU-intensive) deve girare, ma deve farlo con un emulatore sotto che genera codice tutt'altro che ottimizzato (i compilatore JIT online non possono certo fare miracoli, a meno di impiegare ENORMI risorse per tracciare il funzionamento globale del codice. Cosa che ha senso fare, e si fa, soltanto AoT: quando si compila il sorgente).

Tirando le somme, con questi tre handicap mi pare ovvio che i consumi fossero più elevati.

Con Apollolake Intel è riuscita a ottimizzare meglio il processo produttivo (pur rimanendo HP e non LP) e la microarchitettura, migliorando di conseguenza anche i consumi, ma incredibilmente ha deciso di uscire dal mercato del mobile (in pratica senza nemmeno provare). Bah...

Anche lato server esistono il lato legacy e le economie di scala a ivello di manutenzione e supporto del parco hardware e software installato ha il suo bel peso pure li.

Non è un mistero che già da tempo Google faccia girare tranquillamente i suoi server anche su piattaforme POWER di IBM, come pure sia interessata e stia lavorando anche con RISC-V. Architetture che non hanno nulla a che vedere con x86/x64.

Se ci riesce Google, che ha business estremamente variegati in ambito server, vuol dire che il legacy, almeno in quest'ambito, non incida un granché...

[LMCH]

Originariamente inviato da cdimauro

All'epoca a Intel non interessava quella fascia bassa.

I primi Atom, come già detto, erano in-order a 2 vie: per fare "di meno" Intel avrebbe dovuto rispolverare il design del 486 o addirittura del 386. Cosa che ha fatto un po' di anni dopo con la famiglia Quark.

Originariamente inviato da cdimauro

Permettimi: si parlava (anche tu l'hai fatto) di prestazioni, e quindi quei test erano perfettamente pertinenti.

Non erano pertinenti ai casi d'uso di quei dispositivi, in cui i profili di utilizzo davano un vantaggio a chi seppur con prestazioni minori e consumi più alti con le cpu al 100% riusciva aconsumare meno negli altri scenari molto più frequenti.

(consumo batterie nei casi d'uso reali)

Originariamente inviato da cdimauro

Lo era, certamente, ma per altri motivi.

Primo, Intel non usava (e non usa ancora) processi low-power.

Secondo, Intel non aveva nulla di simile al big.little, che è nato apposta per ridurre i consumi.

Già, su questo concordo perfettamente.

Originariamente inviato da cdimauro

Per il terzo vedi sotto.

La retrocompatibilità, invece, era un problema, perché la stragrande maggioranza dei binari (mi riferisco alle app che usano l'NDK qui. Non a quelle Java, che ovviamente non hanno di queste problematiche) che scaricavi/chi dal Playstore sono ARM, e Intel ha dovuto mettere in piedi un emulatore allo scopo (si chiama Houdini), che purtroppo è tutt'altro che perfetto, oltre a richiedere costante manutenzione (causa nuove API di Android e/o nuove app che non funzionano bene con la versione attuale e necessitano di apposite patch).

Questo ovviamente va incidere, e pure molto, sulla batteria, visto che non soltanto il gioco (perché in realtà sono quasi tutti giochi le app che usano NDK, e che quindi sono CPU-intensive) deve girare, ma deve farlo con un emulatore sotto che genera codice tutt'altro che ottimizzato (i compilatore JIT online non possono certo fare miracoli, a meno di impiegare ENORMI risorse per tracciare il funzionamento globale del codice. Cosa che ha senso fare, e si fa, soltanto AoT: quando si compila il sorgente).

Anche questo è vero, ma già con i Cherry Trail il problema "retrocompatibilità ARM" ormai non esisteva più (almeno per app recenti).
In quel periodo sviluppavo app per industria e domotica in cui si andava pesantemente di NDK (per far girare sorgenti C++ codificati in origine per dispositivi desktop ed embedded "fissi") e nonostante si andasse pesanti ed in profondità gli unici dispositivi che davano problemi erano quelli Samsung con SoC Marvell (driver GPU scritti con il cuo, c'era un bug di inizializzazione che veniva re-introdotto ad update alterne, non so se dipendesse da chi gestiva il firmware in Samsung o in Marvell).

Originariamente inviato da cdimauro

Con Apollolake Intel è riuscita a ottimizzare meglio il processo produttivo (pur rimanendo HP e non LP) e la microarchitettura, migliorando di conseguenza anche i consumi, ma incredibilmente ha deciso di uscire dal mercato del mobile (in pratica senza nemmeno provare). Bah...

Su questo sono pienamente d'accordo, almeno su tablet da 10"..13" con display ad alta risoluzione (e batterie belle grosse) già i Cherry Trail si difendevano bene, specialmente se gli si faceva girare sopra qualcosa da "vero" tablet con UI complessa, grafica più pesante e maggior utilizzo di CPU e GPU a piena potenza rispetto al caso d'uso "smartphone".

Originariamente inviato da cdimauro

Non è un mistero che già da tempo Google faccia girare tranquillamente i suoi server anche su piattaforme POWER di IBM, come pure sia interessata e stia lavorando anche con RISC-V. Architetture che non hanno nulla a che vedere con x86/x64.

Se ci riesce Google, che ha business estremamente variegati in ambito server, vuol dire che il legacy, almeno in quest'ambito, non incida un granché...

Se è per questo sia Google che Microsoft lavorano pure sul design di nuove cpu (tipo il progetto EDGE di Microsoft, da non confondere con il browser Edge).

Lo fanno sia per avere sia uno strumento di pressione su Intel quando si tratta di discutere dei costi delle cpu che per avere un piano B (o anche C e D) nel caso discutere non basti più.

Ma non si cambia tipologia di cpu giusto per il gusto di farlo o solo perche si hanno prestazioni superiori senza considerare altri fattori (altrimenti negli anni '90 le cpu Alpha avrebbero spazzato via gli x86).