Apple: unificazione di iOS e OS X su piattaforma ARM?

[Duncan]

!fazz
Infatti lo paragonavo con Atom e se vedi un A9 è comparabile.

Poi l'esempio del grid mi interessa per ambito serve, ottieni una buona ridondanza molto buona e web applicazioni WEb in alcuni ambiti credo sia un'ottima soluzione.

[winebar]

Originariamente inviato da !fazz

devi spiegarmi a cosa gli servono 16 core per andare su facebook dove un comune m3 basta ed avanza

effettivamente ho un po' esagerato coi numeri, che cosa sarebbe un M3 (la BMW la escludo a priori

Originariamente inviato da !fazz

tra un cortex a8 e un 2600k c'è una differenza di prestazioni di oltre 60x e calcolando che l'arm costa si meno di un processore x86 ma non così tanto di meno.

Si è vero la differenza è netta, ma a fronte di una spesa simile col tempo il portafoglio e il conto corrente saranno ben più felici. Ovviamente si può fare in ambiti dove non è necessaria la potenza

[devil_mcry]

Originariamente inviato da Duncan

Intel non ha bisogno di fare reverse engineering dei prodotti ARM, deve solo arrivare ad offrire una piattaforma che abbia le medesime caratteristiche di potenza consumo e personalizzazione, magri con il plus di poter offrire le proprie fonderie che credo si possa affermare siano tra le migliori del mondo per qualità e capacità produttiva.

Se abbraccia ARM rischia di essere strangolata, secondo me. Potrebbe farlo per produrre magari i processori per Apple avere introiti da uno dei più grossi consumatori di chip ARM per poi offri l'alternativa fatta in casa, ha le risorse e la capacità, ma deve agire in fretta.

Sai qual'è stato uno dei più grandi salti evolutivi nell'IT e sopratutto nella diffusione del medesimo? Il concetto di famiglia inventato da IBM nei primi anni 60.

Prima non esisteva, e questo voleva dire riscrivere in continuo codice in assembly. Questo in risposta alla tua prima parte, ovviamente è assurdo pensare ad un entrata di Intel con una nuova famiglia di processori in un segmento dove ARM con Armv6 e Armv7 ne fa da padrona. Chi programmerebbe su un sistema che usi solo tu? Rifare buona parte di roba da 0...

E' non può di certo produrre cpu armv6/7 senza licenze da parte di ARM che ovviamente non gli darà mai

In secondo luogo non credo nemmeno ne abbia l'interesse, arm sta avendo l'evoluzione che c'è stata per le cpu x86 10 anni fa con il boom dei dispositivi ultraportabili, ma si ferma li

voglio vedere quanti cavolo di core cortex a8 devono usare per avere la potenza di un sistema medio quad core odierno... anche su un portatile

prendi un 2720qm intel ad esempio ... ed ha un tdp di 35-45w non 95... (con gpu)

senza scomodare sistemi multi cpu e via discorrendo

Originariamente inviato da Duncan

!fazz
Infatti lo paragonavo con Atom e se vedi un A9 è comparabile.

Poi l'esempio del grid mi interessa per ambito serve, ottieni una buona ridondanza molto buona e web applicazioni WEb in alcuni ambiti credo sia un'ottima soluzione.

Per quanto schifoso un atom, in termini di prestazioni, prima che un cortex A8 raggiunga la sua potenza, sopratutto in calcolo puro, ancora ne passa

Questo è un mito che va avanti da un po di tempo, ma è stato smontato già tempo fa da diversi siti con dei test, sopratutto a livello di FPU, ma come detto sopra sono cpu destinate a ruoli completamente diversi

[Duncan]

Originariamente inviato da devil_mcry

Sai qual'è stato uno dei più grandi salti evolutivi nell'IT e sopratutto nella diffusione del medesimo? Il concetto di famiglia inventato da IBM nei primi anni 60.

Prima non esisteva, e questo voleva dire riscrivere in continuo codice in assembly. Questo in risposta alla tua prima parte, ovviamente è assurdo pensare ad un entrata di Intel con una nuova famiglia di processori in un segmento dove ARM con Armv6 e Armv7 ne fa da padrona. Chi programmerebbe su un sistema che usi solo tu? Rifare buona parte di roba da 0...

E' non può di certo produrre cpu armv6/7 senza licenze da parte di ARM che ovviamente non gli darà mai

Questo vera ero negli anni sessanta, dove si scriveva tanto codice assembly ed anche i compilatori si contavano sulle dita di una mano, ormai non è così da tempo, già almeno dai tempi di Java, poi con .Net ed anche con i compilatori con tecnologia LLVM, l'unica cosa da riscrivere è la parte che si occupa di compilare al volo il codice intermedio generato per l'architettura in uso.

Oltretutto passare da un'architettura ad un'altra non è mai stato un problema se i risparmi e l'efficienza aumentano, basta pensare a tutti i mainframe che esistevano che sono stati piano piano sostituiti con macchine in genere Intel, il software che ci girtava od è stato cambiato o riscritto.

Inoltre stiamo parlando di un eventuale uscita del mercato di prodotti Apple non iOS su architettura ARM, ed Apple ha già tutto, Kernel, sistema operativo a 32 bit, compilatori ecc... non riesco proprio ad immaginare operazione più indolore e come già detto Apple già per Objective-C usa compilatori LLVM (per chi non lo sapesse sta per Low Level Virtual Machine)

P.S.: poi come ho scritto può offrirsi di essere solo fornitore delle fonderie ad Apple per produrre i processori, come A5, A6 ecc, non credo che necessiti di licenza per fabbricare processori di cui la licenza è detentore Apple che decide a chi farli produrre.

Originariamente inviato da devil_mcry

In secondo luogo non credo nemmeno ne abbia l'interesse, arm sta avendo l'evoluzione che c'è stata per le cpu x86 10 anni fa con il boom dei dispositivi ultraportabili, ma si ferma li

voglio vedere quanti cavolo di core cortex a8 devono usare per avere la potenza di un sistema medio quad core odierno... anche su un portatile

prendi un 2720qm intel ad esempio ... ed ha un tdp di 35-45w non 95... (con gpu)

senza scomodare sistemi multi cpu e via discorrendo




Per quanto schifoso un atom, in termini di prestazioni, prima che un cortex A8 raggiunga la sua potenza, sopratutto in calcolo puro, ancora ne passa

Questo è un mito che va avanti da un po di tempo, ma è stato smontato già tempo fa da diversi siti con dei test, sopratutto a livello di FPU, ma come detto sopra sono cpu destinate a ruoli completamente diversi

Infatti Atom l'ho confrontato con A9 non con A8 se poi si vuole continuare a pensare che per vedere 3 pagine web, leggere 2 email e fare altre 4 cose in croce serva per forza una CPU potentissima liberissimi, personalmente ritengo che prossimamente ci saranno tantissimi dispositivi smart ed i computer come oggi li conosciamo diventeranno sempre più roba da appassionati o professionisti (ed intendo programmatori, sistemisti ecc)

[devil_mcry]

Originariamente inviato da Duncan

Questo vera ero negli anni sessanta, dove si scriveva tanto codice assembly ed anche i compilatori si contavano sulle dita di una mano, ormai non è così da tempo, già almeno dai tempi di Java, poi con .Net ed anche con i compilatori con tecnologia LLVM, l'unica cosa da riscrivere è la parte che si occupa di compilare al volo il codice intermedio generato per l'architettura in uso.

Oltretutto passare da un'architettura ad un'altra non è mai stato un problema se i risparmi e l'efficienza aumentano, basta pensare a tutti i mainframe che esistevano che sono stati piano piano sostituiti con macchine in genere Intel, il software che ci girtava od è stato cambiato o riscritto.

Inoltre stiamo parlando di un eventuale uscita del mercato di prodotti Apple non iOS su architettura ARM, ed Apple ha già tutto, Kernel, sistema operativo a 32 bit, compilatori ecc... non riesco proprio ad immaginare operazione più indolore e come già detto Apple già per Objective-C usa compilatori LLVM (per chi non lo sapesse sta per Low Level Virtual Machine)

P.S.: poi come ho scritto può offrirsi di essere solo fornitore delle fonderie ad Apple per produrre i processori, come A5, A6 ecc, non credo che necessiti di licenza per fabbricare processori di cui la licenza è detentore Apple che decide a chi farli produrre.





Infatti Atom l'ho confrontato con A9 non con A8 se poi si vuole continuare a pensare che per vedere 3 pagine web, leggere 2 email e fare altre 4 cose in croce serva per forza una CPU potentissima liberissimi, personalmente ritengo che prossimamente ci saranno tantissimi dispositivi smart ed i computer come oggi li conosciamo diventeranno sempre più roba da appassionati o professionisti (ed intendo programmatori, sistemisti ecc)

guarda che qualunque famiglia ha il suo assembly, prima di ibm il problema era proprio quello, ogni cpu aveva il suo assembly diverso, OGGI si contano sulle dita...

programmare in java e una bella cavolata, come la faccenda del C
la virtual machine può essere scritta in quello che vuoi ma l'ultimo passo nella fase di compilazione e la codifica in codice macchina (o assembly)

non so se hai minimamente idea di come è fatta dentro una cpu da un punto di vista fisico, da come hai risposto non credo, ad ogni modo l'unità di controllo non conosce ne il C ne il java ne il .NET, e tra l'altro il compilatore assembly non fa altro che cambiare le varie istruzioni in una serie di 0-1 che siano in grado di essere capiti dalla macchina a stati finiti dell'unità di controllo (se hardwired) o presenti nella tabella di memoria se microprogrammata

il fatto che java e .net siano portabili è semplicemente dovuto al fatto che non sono linguaggi interpretati, se non c'è la macchina virtuale che fa da interprete hai voglia a farli funzionare...

se l'atom è una cpu potente ammazza ...

[Duncan]

Originariamente inviato da devil_mcry

guarda che qualunque famiglia ha il suo assembly, prima di ibm il problema era proprio quello, ogni cpu aveva il suo assembly diverso, OGGI si contano sulle dita...

programmare in java e una bella cavolata, come la faccenda del C
la virtual machine può essere scritta in quello che vuoi ma l'ultimo passo nella fase di compilazione e la codifica in codice macchina (o assembly)

non so se hai minimamente idea di come è fatta dentro una cpu da un punto di vista fisico, da come hai risposto non credo, ad ogni modo l'unità di controllo non conosce ne il C ne il java ne il .NET, e tra l'altro il compilatore assembly non fa altro che cambiare le varie istruzioni in una serie di 0-1 che siano in grado di essere capiti dalla macchina a stati finiti dell'unità di controllo (se hardwired) o presenti nella tabella di memoria se microprogrammata

il fatto che java e .net siano portabili è semplicemente dovuto al fatto che non sono linguaggi interpretati, se non c'è la macchina virtuale che fa da interprete hai voglia a farli funzionare...

se l'atom è una cpu potente ammazza ...

Faccio il programmatore da diversi anni ed ho sempre lavorato nel settore, forse un'idea di quello che dico la ho.

Le VM son state fatte proprio per rendere facile la portabilità senza riscrivere i programmi, infatti esistono VM Java praticamente per ogni architettura esistente.


Per LLVM ad esempio c'è tantissima documentazione su come fare un nuovo compilatore per il codice intermedio per un nuovo target, oltetutto ogni volta che vengono aggiunti nuovi set di istruzioni alle CPU non mi pare che siano in molti a stracciarsi le vesti per l'immane lavoro da fare per aggiungerle nei compilatori e sfruttarle adeguatamente.

La portabilità di un linguaggio, poi, non dipende dal fatto che sono interpretati, ma da come sono scritti i programmi e se esiste un compilatore od interprete per l'architettura target, infatti per .Net ci sono diversi problemi a fare un programma in VS 2010 e poi farlo girare su Linux con Mono... mentre per Java in genere è assai più semplice perchè esistono VM per vari SO e per varie architetture.

Poi parlavo di Atom perché è la CPU di Intel che sta perdendo quote nei confronti delle soluzioni basate su ARM, altrimenti perché non parlare anche delle IBM POWER7 ?

[devil_mcry]

Originariamente inviato da Duncan

Faccio il programmatore da diversi anni ed ho sempre lavorato nel settore, forse un'idea di quello che dico la ho.

Le VM son state fatte proprio per rendere facile la portabilità senza riscrivere i programmi, infatti esistono VM Java praticamente per ogni architettura esistente.


Per LLVM ad esempio c'è tantissima documentazione su come fare un nuovo compilatore per il codice intermedio per un nuovo target, oltetutto ogni volta che vengono aggiunti nuovi set di istruzioni alle CPU non mi pare che siano in molti a stracciarsi le vesti per l'immane lavoro da fare per aggiungerle nei compilatori e sfruttarle adeguatamente.

La portabilità di un linguaggio, poi, non dipende dal fatto che sono interpretati, ma da come sono scritti i programmi e se esiste un compilatore od interprete per l'architettura target, infatti per .Net ci sono diversi problemi a fare un programma in VS 2010 e poi farlo girare su Linux con Mono... mentre per Java in genere è assai più semplice perchè esistono VM per vari SO e per varie architetture.

Poi parlavo di Atom perché è la CPU di Intel che sta perdendo quote nei confronti delle soluzioni basate su ARM, altrimenti perché non parlare anche delle IBM POWER7 ?

Fai il programmatore e non sai come funziona un compilatore o una unità di controllo ???

Ecco perchè e tanto inflazionato il nostro settore...

Inutile spendere altre parole... vivi nella convinzione che scrivere un os per un'altra famiglia di cpu si fa per magia

[Duncan]

Originariamente inviato da devil_mcry

Fai il programmatore e non sai come funziona un compilatore o una unità di controllo ???

Ecco perchè e tanto inflazionato il nostro settore...

Inutile spendere altre parole... vivi nella convinzione che scrivere un os per un'altra famiglia di cpu si fa per magia

Casa ci sarebbe di così probitivo nello scrivere un SO per un'altra architettura?
Sinceramente ci sono vari sistemi multipiattaforma ognuno con il suo bel kernel scritto in C (spesso) e piccoli moduli in assembly.

Non mi pare che, per esempio Apple si sia fatta problemi a passare da PowerPC ad Intel e poi fare un SO per ARM, come la stessa Microsoft.

la differenza principale è che mi pare tu pensi che scrivere un compilatore sia un'impresa Titanica.

P.S.: prima di scrivere che un interlocutore non conosce una cosa sarebbe bene pensarci bene prima.

Poi dove avrei scritto che si scrive per magia un SO? Mah...

[devil_mcry]

Originariamente inviato da Duncan

Casa ci sarebbe di così probitivo nello scrivere un SO per un'altra architettura?
Sinceramente ci sono vari sistemi multipiattaforma ognuno con il suo bel kernel scritto in C (spesso) e piccoli moduli in assembly.

Non mi pare che, per esempio Apple si sia fatta problemi a passare da PowerPC ad Intel e poi fare un SO per ARM, come la stessa Microsoft.

la differenza principale è che mi pare tu pensi che scrivere un compilatore sia un'impresa Titanica.

P.S.: prima di scrivere che un interlocutore non conosce una cosa sarebbe bene pensarci bene prima.

I microprocessori puramente RISC come gli ARM hanno bisogno di una forte ottimizzazione del codice per poter lavorare bene

Scrivere un compilatore non è un'impresa titanica (sopratutto assembly), ma l'ottimizzazione del codice non è banale come la fai tu. Non basta cambiare il la codifica delle istruzioni per avere lo stesso risultato !

Apple non ha avuto problemi a passare da powerpc a x86 in quanto i kernel di derivazioni unix x86 non erano una novità, ARM stessa è una realtà ben presente da anni nei kernel linux

Io voglio vedere (e qui apple non centra una bella fava io nn l'ho mai citata) quale azienda si prende la briga di buttarsi su una nuova famiglia di cpu, con una struttura diversa che ha bisogno di ottimizzazioni sicuramente diverse quando ha da un lato un sistema collaudato, un buon know how e soluzioni già pronte solo da eventualmente modificare.

Tu lo faresti?

[Duncan]

Originariamente inviato da devil_mcry

I microprocessori puramente RISC come gli ARM hanno bisogno di una forte ottimizzazione del codice per poter lavorare bene

Scrivere un compilatore non è un'impresa titanica (sopratutto assembly), ma l'ottimizzazione del codice non è banale come la fai tu. Non basta cambiare il la codifica delle istruzioni per avere lo stesso risultato !

Apple non ha avuto problemi a passare da powerpc a x86 in quanto i kernel di derivazioni unix x86 non erano una novità, ARM stessa è una realtà ben presente da anni nei kernel linux

Io voglio vedere (e qui apple non centra una bella fava io nn l'ho mai citata) quale azienda si prende la briga di buttarsi su una nuova famiglia di cpu, con una struttura diversa che ha bisogno di ottimizzazioni sicuramente diverse quando ha da un lato un sistema collaudato, un buon know how e soluzioni già pronte solo da eventualmente modificare.

Tu lo faresti?

Secondo te, quindi, se Intel decidesse di lanciare una nuova architettura abbandonerebbe i clienti a scriversi un compilatore per conto loro? Già ai tempi di Itanium (al di la del poco successo avuto da questa architettura che non è certo nel poco supporto dei compilatori) abbiamo visto che di supporto per avere compilatori anche non Intel per la CPU ne ha dato parecchio, il problema, secondo me non sta li.

Un azienda lo fa se lo ritiene vantaggioso, se l'eventuale alternativa proposta ad ARM si dimostra in grado di avere prestazioni simili per prestazioni e consumi e con costi inferiori, perché no? Se fosse meglio anche per prestazioni e consumi sicuramente. (Ho messo prima i costi proprio perché se deve decidere, un'azienda decide su quello, una volta fatto il porting i costi poi non crescono certamente con ogni unità venduta, i risparmi si)

[devil_mcry]

Intel che di punto in bianco tiri fuori una soluzione competitiva con quella di un'azienda presente nel suo settore da 30anni, con un compilatore perfetto al primo colpo, che costi meno, con un porting indolore e magari prestazioni superiori... Non è un po utopico? Rimaniamo con i piedi per terra dai...

[Duncan]

Originariamente inviato da devil_mcry

Intel che di punto in bianco tiri fuori una soluzione competitiva con quella di un'azienda presente nel suo settore da 30anni, con un compilatore perfetto al primo colpo, che costi meno, con un porting indolore e magari prestazioni superiori... Non è un po utopico? Rimaniamo con i piedi per terra dai...

Come a me pare utopico pensare che Intel resti a guardare mentre ARM conquista quote di mercato, con smartphone e netbook, mini pc ecc.

Le alternative che ha mi pare siano due, od architettura nuova pensata per combattere con ARM o fare un grosso step su Atom sia come prestazioni che come consumi, non è che ha molte altre strade.

[devil_mcry]

mannaggia al portale, e la 3° volta che riscrivo questo post

Il mercato degli smartphone è dominato da ARM da sempre, non ci vedo novità
Vedo più un interesse ad entrare nel segmento dei tablet, anche in virtù di alcuni esperimenti mal riusciti di tablet basati su ATOM

Vediamo ora l'aspetto netbook, un A9 se la vede ad oggi al massimo con un atom N270/N455 (dove ipc e prestazioni non differiscono), un ipotetico quad core A10 se la vedrebbe con un atom N550? forse, ... si però, entro fine anno escono le soluzioni N2600-N2800 che portano una ventata fresca tra gli atom con incrementi di ipc e altro, inoltre c'è bobcat di AMD

Dal punto di vista prestazionale al massimo siamo tra ora e l'anno prossimo ai livelli dei netbook più economici che ci sono in giro

C'è il fattore consumi, consumi bassi, ma netbook con A9 già li hanno proposti e l'autonomia non particolarmente superiore a un netbook normale ( con un A9 per me un netbook a 6 celle potrebbe farsi circa 24 ore di autonomia) ma non la mettono...

[Duncan]

Come dici su A9 mettono batterie più piccole per avere la stessa autonomia, così abbassano il prezzo e come dici a prestazioni siamo li con Atom, con i prossimi vedremo quando usciranno, ma se Intel si vuol dare una svecchiata ad Atom sarà comunque sempre costretta a mettere parte dello spazio per lo traduzione delle istruzioni x86 spazio che quando faccio produrre le CPU pago, per questo Atom è penalizzato come rapporto prestazioni/consumi/dimensione rispetto ad ARM che è pensato dalle fondamenta per l'efficienza energetica.

P.S: Poi come dici ARM su smartphone c'è da sempre, ma se pensi che viene dal mondo embeded e da li ha cominciato l'arrampicata, continuo a pensare che Intel non debba dormire sugli allori delle prestazioni.

[simon71]

Originariamente inviato da Duncan

Casa ci sarebbe di così probitivo nello scrivere un SO per un'altra architettura?
Sinceramente ci sono vari sistemi multipiattaforma ognuno con il suo bel kernel scritto in C (spesso) e piccoli moduli in assembly.

Non mi pare che, per esempio Apple si sia fatta problemi a passare da PowerPC ad Intel e poi fare un SO per ARM, come la stessa Microsoft.

la differenza principale è che mi pare tu pensi che scrivere un compilatore sia un'impresa Titanica.

P.S.: prima di scrivere che un interlocutore non conosce una cosa sarebbe bene pensarci bene prima.

Poi dove avrei scritto che si scrive per magia un SO? Mah...

Giusto per chiarire...Apple non ha dovuto riscrivere niente.
Osx fin dalle sue fondamenta si trascinava dietro "le istruzioni" X86...

Quando Apple è passata ad Intel non ha fatto altro che togliere quelle per PPC. (con Snow Leopard)...

[simon71]

Per concludere....Inutile accapigliarsi...

Inutile discutere di potenza di calcolo, di CPU, di TPd, di frequenze e altre menate...

Qui stiamo parlando della massa...E la massa ha già scelto...Per il 90% dell'utenza la "potenza" di un Pad è più che sufficiente per fare quelle 4 cose che sono richieste...

Prevedo in un futuro delle TV con Modem annesso a CPU (atom, Arm, non importa) che consenta giusto di gestire le Foto delle vacanze e/o i filmini...

I Computer come è stato detto resteranno una nicchia per professionisti...Dall' audio/video editor alla medicina, dalla ricerca alla scienza in genere, fino ai sistemi...

Ricordo fino a pochissimi anni fa (non parlo degli anni dei Garibaldini) l'apice dei computer Desktop, i case moddati con le lucine, i flash, i raid di Hdd eccetera eccetera...

Poi, quasi improvvisamente (pochissimi anni) i Notebook hanno surclassato i Pc Desktop in ambito Home...Solo i Gamers hanno continuato a comprarli e/o assemblarli..

Poi sono arrivati i Net...Ora i Tablet...

[Duncan]

@simon71

Concordo, la tendenza è quella ed è la solita che ha premiato Intel e Microsoft, c'è da vedere se queste aziende sapranno rinnovarsi o saranno travolte, naturalmente tutto questo IMHO.

[!fazz]

Originariamente inviato da Duncan

!fazz
Infatti lo paragonavo con Atom e se vedi un A9 è comparabile.

Poi l'esempio del grid mi interessa per ambito serve, ottieni una buona ridondanza molto buona e web applicazioni WEb in alcuni ambiti credo sia un'ottima soluzione.

non è che poi sia così comparabile eh, calcola che il bench sintetico di 7zip favorisce nettamente i processori più poveri in quanto è un bench molto di basso livello (nessun calcolo a virgola mobile e nessun uso di sse che danno enormi vantaggi ai processori x86 rispetto agli arm)

Originariamente inviato da winebar

effettivamente ho un po' esagerato coi numeri, che cosa sarebbe un M3 (la BMW la escludo a priori



Si è vero la differenza è netta, ma a fronte di una spesa simile col tempo il portafoglio e il conto corrente saranno ben più felici. Ovviamente si può fare in ambiti dove non è necessaria la potenza

l'm3 è un'altra famiglia di processori arm a 32 bit
http://www.arm.com/products/processo.../cortex-m3.php

ovviamente dove non serve potenza di calcolo una soluzione arm ti permette di consumare enormemente meno ma come ho detto già nei post precedenti i processori arm sono molto più semplici e grezzi rispetto ai processori x86 ed è per questo che consumano così poco

[Duncan]

Vero, comunque dipende dall'implementazione, la FPU è opzionale e ci sono anche set di istruzioni tipo SSE, comunque un sistema A8 consuma anche 5w un A9 credo che arrivi al doppio massimo (e sto abbondando perché non trovo nulla di certo velocemente)

[!fazz]

Originariamente inviato da Duncan

Vero, comunque dipende dall'implementazione, la FPU è opzionale e ci sono anche set di istruzioni tipo SSE, comunque un sistema A8 consuma anche 5w un A9 credo che arrivi al doppio massimo (e sto abbondando perché non trovo nulla di certo velocemente)

a occhio i dati sono plausibili, purtroppo anche io non ho esperienza diretta con gli a9 ma conosco molto bene gli m3 e anche quelli quando gli tiri il collo non sono per nulla parchi nei consumi ma calcola anche che un SoC è diverso da un processore al suo interno contiene parecchie periferiche che un pc tradizionale non ha (es ADC e CAN ed eventualmente radio) che lo portano a consumare comunque di più

come sempre il consumo è legato alle funzionalità: maggiori funzionalità comportano un maggior numero di transistor che direttamente portano ad un aumento dei consumi aggiungi anche un clock veloce e il fatto che se vuoi potenza di calcolo abbastanza continuativa (come in un pc tradizionale) sleep e stop mode non sono utilizzabili quindi il SoC funziona sempre al 100%