Link alla notizia: https://www.hwupgrade.it/news/cpu/snapdragon-1000-fino-a-12-w-per-competere-con-intel-tramite-windows-on-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.

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

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

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)

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

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.

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

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

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.

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?

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

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.

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

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.

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.

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.

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? (http://www.extremetech.com/extreme/188396-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. ;)

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.


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? (http://www.extremetech.com/extreme/188396-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).


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)



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.

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

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.


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)

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.


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 cu:ciapet:o, 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).


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


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

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.
Questo è senz'altro vero. D'altra parte la piattaforma low-cost di Intel di allora oggettivamente non poteva nemmeno essere classificata come mobile (smartphone, table).
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 cu:ciapet:o, 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).
Purtroppo anche per le applicazioni & giochi moderni non tutti venivano compilati per più architetture. Ricordo che all'epoca c'erano delle pagine che riportavano i giochi nativi e quelli emulati, le problematiche di queste ultime, e non c'erano soltanto giochi vecchi.
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".
Ecco un'altra cosa che avevo dimenticato di citare prima: la GPU. Intel non ha mai prodotto GPU aventi prestazioni elevate e/o con consumi ridotti.

E si andava a scontrare con GPU pensate appositamente per il mobile...

Vero che le ultime versioni degli Atom montavano GPU più potenti e ottimizzate, ma Adreno e Mali erano meglio ottimizzate per gli scenari mobile.
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).
Sì, lo conosco e ho letto un po' di documentazione tempo fa, ma non mi sembra un'architettura general purpose.
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).
Beh, è ben noto che Intel sviluppa apposite estensioni (istruzioni) per specifici grossi clienti, però son cose che Google & co. possono benissimo farsi in casa (come peraltro hanno già dimostrato).

Sì, lo conosco e ho letto un po' di documentazione tempo fa, ma non mi sembra un'architettura general purpose.


Sui prototipi implementati su FPGA hanno fatto il porting sia di Windows 10 che di Linux.
( Fonte: https://www.theregister.co.uk/2018/06/18/microsoft_e2_edge_windows_10/ )
Nell"articolo parlano anche di una cooperazione tra Microsoft e Qualcomm per sviluppare due cpu EDGE chiamate R0 ed R1.

E' proprio uno degli articoli che avevo letto. :D

Dentro c'è un link a una pagina rimossa, ma che è stata resa accessibile grazie a archive.org, con maggiori dettagli su come funziona EDGE. ;)

E' proprio uno degli articoli che avevo letto. :D

Dentro c'è un link a una pagina rimossa, ma che è stata resa accessibile grazie a archive.org, con maggiori dettagli su come funziona EDGE. ;)

La cosa più interessante di tale architettura è che dovrebbe scalare molto bene una volta messo a punto il backend di ottimizzazione dei compilatori per essa, visto che da un lato rende possibile ad esempio semplificare il loop unrolling e più in generale vettorizzare automaticamente un sacco di codice "sequenziale", mentre dall'altro lato permette di mixare le istruzioni provenienti da più thread in un unico pool di unità di esecuzione.
Nel senso che codice ottimizzato per un R1 32-way gira bene anche su un R0 con solo 8 -way e viceversa, specialmente se ci sono altri thread in esecuzione ed al tempo stesso si riduce enormemente la gestione delle interdipendenze e lo scheduling lato cpu.

Ovviamente se il compilatore non fa bene il suo lavoro poi c'e' il rischio di ritrovarsi con i problemi riscontrati in precedenza su Intel EPIC/Itanium e sul Cell di IBM, ma a differenza di questi due l'architettura EDGE dovrebbe dare buoni risultati anche con core più "semplici" (per sistemi embedded a basso consumo) o che disattivano unita di esecuzione dinamicamente per ridurre i consumi in base al carico computazionale ed altro.

Eh, ma è proprio quello il problema: nessun compilatore potrà mai generare codice in grado di competere con la "visione" ciclo di clock per ciclo di clock e il conseguente "dispatch" delle istruzioni a runtime.

Itanium docet, per l'appunto. :D

Eh, ma è proprio quello il problema: nessun compilatore potrà mai generare codice in grado di competere con la "visione" ciclo di clock per ciclo di clock e il conseguente "dispatch" delle istruzioni a runtime.

Itanium docet, per l'appunto. :D
Se non ho capito male, è un approccio differente dall'EPIC di Itanium.
Usano una codifica delle istruzioni e delle informazioni su interdipendenze e dataflow che è più efficiente e si presta bene anche al multithreading.
Semplicemente la cpu non spreca area sul chip e logica di scheduling per "ricostruire parzialmente" le informazioni di ottimizzazione e parallelizzazione che il compilatore estrare anche per le altre cpu, quindi si possono realizzare cpu più semplici a parità di ipc medio oppure che fanno scheduling più sofisticato visto che non devono "riscoprire" quello che gli può già dire il compilatore.
Con EPIC il compilatore doveva ottimizzare molto di più tenendo conto dello specifico numero di unità di esecuzione differenti ecc. ecc. (è c'erano un sacco di feature che si intralciavano tra loro) con EDGE invece sembra che vi sia un maggior equilibrio,dove compilatore e cpu si limitano a fare quello in cui eccellono senza intralciarsi troppo.

Guarda, alla fine è esattamente lo stesso principio dei VLIW prima e di EPIC/Itanium poi.

Puoi ottimizzare quanto ti pare e codificare come meglio credi le dipendenze: non potrai MAI prevedere al 100% le branch misprediction e i tempi delle load (e anche store, se ci mettiamo di mezzo la paginazione), schedulando di conseguenza le istruzioni da eseguire.

L'approccio di EDGE, dunque, può senz'altro andare bene per codice "più lineare", ma per quello "general purpose" certamente no: è molto meglio un processore out-of-order tradizionale.

Puoi ottimizzare quanto ti pare e codificare come meglio credi le dipendenze: non potrai MAI prevedere al 100% le branch misprediction e i tempi delle load (e anche store, se ci mettiamo di mezzo la paginazione), schedulando di conseguenza le istruzioni da eseguire.

Però è anche vero il contrario una CPU non avrà mai (o facilmente a certi costi) le risorse necessarie (e tra le risorse figura anche il tempo) per computare tutte le combinazioni necessarie per estrapolare un elevato parallelismo dal codice (se questo parallelismo esiste).

Solo un ottimo compilatore può scoprire che con un certo ordine si può mandare in parallelo magari 32 istruzioni sul singolo core (naturalmente avendo le unità funzionali necessarie).
Haswell per esempio mi pare che oltre 8 istruzioni (poi istruzioni micro-ops) non riesca ed è già un gran numero, altre archittetture (tra cui gli arm almeno fino a A57) oltre 3 o 4 non si spingono.

Quindi la schedulazione dinamica della cpu dovrà sempre essere aiutata da un buon codice ottimizzato e se si vuole andare oltre certi livelli di parallelismo ci vorrà probabilmente la schedulazione statica ed un compilatore in grado saturare le unità funzionali presenti.

Diciamo che generalmente più un codice è parallelizzabile, e più è conveniente utilizzare processori vettoriali, o addirittura si passa direttamente al modello GPU.

E' vero che i processori x86/x64 di Intel sono in grado di eseguire max 8 uop per ciclo di clock (sono 10 per Ryzen). Sul versante ARM il massimo in tal senso è rappresentato da Project Denver di nVidia, che pur non essendo un processore nativo ARM arriva a eseguire fino a 7 istruzioni ARM per ciclo di clock; seguito a ruota da Apple, con max 6 per ciclo di clock (ecco perché i core di Apple sono molto grossi paragonati a quelli della concorrenza, e con prestazioni così elevate).

Però ma una uop può anche eseguire un'operazione SIMD, e quindi su più dati allo stesso momento (con AVX512 di Intel che arriva a max 64 operazioni su byte e fino a max 8 operazioni in virgola mobile a precisione doppia).

Quindi un processore general purpose moderno ha pure abbastanza risorse e capacità per eseguire un certo numero di operazioni per ciclo di clock.

Ovviamente non potrà mai eccellere sul versante parallelo, perché soluzioni come quelle di cui abbiamo parlato finora si prestano decisamente meglio.

Alla fine il concetto rimane sempre lo stesso: non esiste la soluzione in grado di avere prestazioni migliori su tutti gli ambiti applicativi. Ed è anche il motivo per cui i processori moderni sono affiancati da coprocessori diversi (GPU in primis, ma anche DSP per l'audio e/o per elaborazione di immagini, Quicksync per transocodifica video, ecc.).

P.S. Servono anche buoni compilatori, ovviamente, anche per processori general purpose e fortemente out-of-order.

Guarda, alla fine è esattamente lo stesso principio dei VLIW prima e di EPIC/Itanium poi.

Puoi ottimizzare quanto ti pare e codificare come meglio credi le dipendenze: non potrai MAI prevedere al 100% le branch misprediction e i tempi delle load (e anche store, se ci mettiamo di mezzo la paginazione), schedulando di conseguenza le istruzioni da eseguire.

L'approccio di EDGE, dunque, può senz'altro andare bene per codice "più lineare", ma per quello "general purpose" certamente no: è molto meglio un processore out-of-order tradizionale.

Il vantaggio di EDGE rispetto a VLIW ed EPIC sta nell'usare le informazioni che il compilatore "conosce già", senza pretendere che sia il compilatore a farsi carico di tutto.

EDGE è strutturato in più core fisici che possono essere raggruppati in core logici con maggior parallelismo interno e questo lo decide il compilatore in base a quante istruzioni riesce a parallelizzare, quindi si ha comunque una maggior efficienza nell'utilizzo delle unita di esecuzione (se il compilatore "vede" che non riesce a parallelizzare a sufficienza, seleziona un singolo core fisico, lasciando più risorse per eseguire altri thread/processi).

Poi l'implementazione dei core fisici può essere n-way, in-order o out-of-order, in base a cosa è più importante per un certo tipo di cpu, SoC o macrocella.

Mi sembra decisamente più versatile rispetto a VLIW ed EPIC e con molto più margine di crescita rispetto ad un "classico" sistema multicore out-of-order.

EDGE può cercare di spremere il massimo che un compilatore possa fare, ma rimangono i limiti dei compilatori, che non possono prevedere tutto, per l'appunto.

Alla fine mi sono fatto la seguente, personalissima nonché banale, idea: l'esecuzione out-of-order non esisterebbe se i compilatori fossero in grado di farsi carico di tutto il lavoro di ottimizzazione & schedulazione delle istruzioni.

Per questo dubito che EDGE possa trarre vantaggio dall'uso di eventuali core out-of-order: come fai a "parallelizzare" a compile time raggruppando istruzioni tenendo conto che poi queste istruzioni potrebbero avere problemi in esecuzione?

Il lavoro di EDGE, peraltro, riescono già a farlo degli ottimi compilatori, se si tratta di (auto)vettorizzare il codice e/o di distribuire il carico di lavoro su più core.

Se vantaggio c'è in questa nuova architettura, continua a essere difficile notarlo in ambito più general purpose.