Intel: Bay Trail è più potente ed efficiente di Apple A7

[calabar]

@PaulGuru
Gli A9 sono due generazioni indietro.
Rispetto agli A9 gli A15 hanno un 30-40% di ipc in più.
Gli A57 sono ben altro che A15 con i 64 bit.

L'A7 di apple, un dual core a 1,3GHz, va quanto uno Snapdragon 800 (paragonabile ad un quad A15) a 2.26 Ghz. Fatti un po' di conti.
Come vedi, devi un po' rivedere le tue stime.
Se Intel sforna nuovi SOC, gli altri non stanno dormendo.

Per la portabilità, sei ormai così abituato alla ridicola durata delle batterie odierne che più di una giornata ti sembra "in più". A me sembra una scocciatura enorme, vorrei che questi dispositivi durassero una settimana. Eppure qualche anno fa i telefoni duravano quel tanto.

[PaulGuru]

Originariamente inviato da calabar

@PaulGuru
Gli A9 sono due generazioni indietro.
Rispetto agli A9 gli A15 hanno un 30-40% di ipc in più.
Gli A57 sono ben altro che A15 con i 64 bit.

L'A7 di apple, un dual core a 1,3GHz, va quanto uno Snapdragon 800 (paragonabile ad un quad A15) a 2.26 Ghz. Fatti un po' di conti.
Come vedi, devi un po' rivedere le tue stime.
Se Intel sforna nuovi SOC, gli altri non stanno dormendo.

Per la portabilità, sei ormai così abituato alla ridicola durata delle batterie odierne che più di una giornata ti sembra "in più". A me sembra una scocciatura enorme, vorrei che questi dispositivi durassero una settimana. Eppure qualche anno fa i telefoni duravano quel tanto.

A57 da quanto ho letto non porta significativi margini, la novità più grande erano i 64bit, che Apple A7 sia paragonabile a Snapdragon 800 dove lo hai visto ? Potresti gentilmente linkare qualche bench serio a riguardo che non siano quelle cavolate del browser o bench openGL.

Ma mettiamo caso che sia vero, quanto farebbe in più ? 40-50% ? Sempre pochissimo, Intel viaggia con +200-300%.

[calabar]

@PaulGuru
Ma scusa... ti ho appena scritto sopra quanto vanno (e sono stato generoso), e tu mi dici "quanto farebbe in più? 40-50%?" ?
Direi che sugli A57 hai letto male, si passa a nuove istruzioni (ARMv8) e l'architettura ha subito miglioramenti.
Per i benchmark, non ho link pronti da darti ma trovi ne facilmente diversi con una ricerca.

[PaulGuru]

Originariamente inviato da marcoplacido

http://www.anandtech.com/show/7335/t...ne-5s-review/5

Browsermark ? Mozzilla, Chrome e Javascript ? Questi sarebbe i bench che mostrano la potenza di una cpu ?
Non so nemmeno se sfruttano tutti i cores nè se è influenzato dalla GPU.
Android gioca chiaramente sul fatto che non esistano veri bench tipo cinebench su di esso così può mascherare il tutto.

[calabar]

Beh certo, quando i benchmark dicono cose che non ci piacciono, allora quei benchmark non vanno bene...

Dai, ti basta cercare in giro e trovi ogni tipo di benchmark. L'A7 va come un quad core di precedente generazione pur avendo la metà dei core e della frequenza.

Benchmark come Cinebench non hanno senso su dispositivi di questo tipo, sia perchè nessuno al momento utilizzerebbe un dispositivo di questo tipo per fare rendering, sia perchè nella piattaforma mobile molte attività sono svolte da hardware specifico: non conta la forza bruta in se, ma come vengono svolti i compiti.
Il Moto X ha dimezzato la potenza del proprio SOC rinunciando a due core, inserendo al loro posto dei processori dedicati al linguaggio naturale e alla gestione dei sensori. Ha fatto una scelta che ha garantito un valore aggiunto notevole allo smartphone, pur riducendone la potenza.
Se non capisci il perchè di questo, allora non mi sorprende che tu non capisca perchè i SOC Intel hanno tanta difficoltà in questo mercato.

[PaulGuru]

Originariamente inviato da marcoplacido

e allora fallo te un bench se non ti và nemmeno bene anan…..
p.s: ti ho postato uno di quelli più attendibili ,come dice calabar ce ne sono un'infinità. a te la scelta

Mi spiace, ho trovato solo quelli.

Comunque nemmeno io faccio girare il Cinebench perchè faccio rendering, prima di tutto era un esempio per rendere l'idea, intendevo un bench che possa misurare appieno la potenza della cpu in toto e che sia direttamente paragonabile quindi che sia largamente usato e diffuso.

Bisogna separare 2 discorsi, il primo è il ragionamento da Tablet come strumento semplice elementare, l'altro è la possibilità di farsi un TabletPC ed essere curiosi su come la piattaforma sarà in grado di farci girare l'OS desktop visto che non è scontata la cosa anzi è stata a lungo il tallone d'Achille del precedente Atom.

[LMCH]

Originariamente inviato da PaulGuru

ARM è sempre stato inferiore agli x86 nelle prestazioni, questo bay trail è il colpo di grazia, non c'è mica da stupirsi che abbia sodomizzato Apple.

Veramente quando erano progettati con lo stesso inviluppo termico e per lo stesso tipo di applicazioni gli ARM spaccavano il cuo agli x86.

L' ARM2 con circa 30mila transistor ed 8Mhz di clock superava in prestazioni gli 80286 con 134mila transistor a 10Mhz di clock.
Cioè con un 20% di clock in meno e circa 1/4 dei transitor erano migliori del top degli x86 di quel periodo.

Non presero piede perche in quel periodo venivano usati sugli Acorn e ad andare per la maggiore erano gli MC6800 e derivati (usati dai Mac, Amiga, Atari ST) e gli x86 (usati con MS-DOS sui pc) e già allora la retrocompatibilita era importante.
Poi comunque si ritagliarono una loro nicchia nel settore embedded visto che l'alta efficienza che poteva essere usata per ottenere prestazioni superiori si poteva utilizzare anche per ottenere consumi molto più bassi della con concorrenza.

Anche ora del resto Intel può parlare quanto vuole ma c'è un motivo se ha fatto una fatica enorme per ridurre i consumi e per integrare sui SoC le stesse funzionalità che per i SoC ARM non creano altrettanti problemi usando tecnologie di produzione inferiori.

Ed ora, con l'arrivo di ARMv8 (64bit) ed il diffondersi sempre maggiore di software multipiattaforma o di software che spesso gira solo su ARM, Intel deve iniziare a preoccuparsi che qualche produttore "per roba ad alte prestazioni" inizi a proporre cpu ARM per server di fascia alta.

[PaulGuru]

Si e perchè ora han preso piede ? Per via delle performance che crescendo han permesso a questo tipo di prodotti di far girare finalmente qualcosa di importante, quindi tutto gira attorno a quello, la prestazione.

Atom anche nelle precedenti generazioni era superiore agli ARM, solamente restituiva una pessima esperienza con Windows specialmente il 7, mentre sugli ARM ci piazzavano Android che girava benino ( e ce credo era molto più leggero ).

Gli ARM non sono capaci di fornire alti livelli di IPC per core al pari degli x86, gli esempi che stai facendo penso siano da ridiscutere.
Intel all'epoca non ha mai investito in quelle fasce nè ha mai fatto sul serio.

Una domanda da porsi è : quando questi Atom col tempo riusciranno magari anche rimanendo sempre dietro con l'efficienza energetica a far girare qualcosa di importante in più rispetto agli ARM pensi veramente che la storia rimarrà uguale.

[gilles17871]

Originariamente inviato da PaulGuru

Si e perchè ora han preso piede ? Per via delle performance che crescendo han permesso a questo tipo di prodotti di far girare finalmente qualcosa di importante, quindi tutto gira attorno a quello, la prestazione.

Atom anche nelle precedenti generazioni era superiore agli ARM, solamente restituiva una pessima esperienza con Windows specialmente il 7, mentre sugli ARM ci piazzavano Android che girava benino ( e ce credo era molto più leggero ).

Gli ARM non sono capaci di fornire alti livelli di IPC per core al pari degli x86, gli esempi che stai facendo penso siano da ridiscutere.
Intel all'epoca non ha mai investito in quelle fasce nè ha mai fatto sul serio.

Una domanda da porsi è : quando questi Atom col tempo riusciranno magari anche rimanendo sempre dietro con l'efficienza energetica a far girare qualcosa di importante in più rispetto agli ARM pensi veramente che la storia rimarrà uguale.

Sostanzialmente ha ragione, ma per far rendere bene l'architettura arm bisogna scrivere codice altamente ottimizzato (si ci sono i compilatori, ma non fanno miracoli).
Le architetture x86 da sempre sono state in grado di digerire codice fatto con i piedi e le implementazioni di nuove istruzioni servono anche a rendere più efficente il codice semplificandolo.
Con software molto complessi sarà sempre più difficile per arm fallo girare velocemente, mentre dall'altra parte sono i compilatori per x86 a dare una mano nell'ottimizzazione.
Quindi credo che per ancora molto tempo (in scala temporale informatica) arm sarà delegato a piccoli carichi, e se non sbaglio è da adesso che le architetture arm hanno un approcio ooo che aiutano nelle prestazioni pure a scapito di una minor efficenza energetica.

[LMCH]

Originariamente inviato da PaulGuru

Si e perchè ora han preso piede ? Per via delle performance che crescendo han permesso a questo tipo di prodotti di far girare finalmente qualcosa di importante, quindi tutto gira attorno a quello, la prestazione.

No. Le prestazioni contano fino ad un certo punto.

Gli x86 fino a circa il 1990 le prendevano da tutti in termini di prestazioni.

Quello che gli ha permesso di "vincere" sul lungo termine è stata la retrocompatibilita con il software per MS-DOS prima e per Windows poi.

Negli anni '80 sia gli ARM che gli MC68000 e derivati prendevano a calci in cuo gli x86, fino a circa inizio 2000 erano state poi le cpu Alpha di DEC ad essere le più potenti.
Solo che se volevi far girare Wordperfect, Lotus 123, Dbase IV, ecc. ecc. e poi Office, Autocad, ecc. indovina quale era la cpu da usare ?

A fare la fortuna di Intel furono gli ingegneri della sede IBM di Boca Raton (Florida) che avendo mano libera nel progettare un personal computer (su cui IBM credeva poco, ma che voleva averne uno "suo" per avere una linea di prodotti completa dai Mainframe giù fino a personal computer che allora erano Apple II e roba basata su S.O. CP/M e cpu Z80) decisero di utilizzare un 8088 (la cpu più scrausa della linea 8086).
La ragione di tale scelta fu che le altre cpu allora utilizzate sui personal computer erano il 6502 e derivati e l'Intel 8080 e cloni e derivati (tra cui lo Z80) ovvero tutte cpu ad 8bit, mentre scegliendo l'8088 anche se aveva il bus dati ad 8 bit potevano dire di avere una cpu a 16bit ed in teoria era pure possibile crosscompilare dei sorgenti assembly per 8080 per farli girare "ad 8bit" su 8086/8088.

Inizialmente a fare traino furono quelle che allora erano tre lettere magiche: IBM.
Anche chi non ne capiva una cippa sapeva che IBM faceva "la roba che usano le aziende grosse" ed era il nome più noto di produttore di computer tra le masse.
Poi le specifiche del primo PC XT IBM erano praticamente pubbliche e quindi era facile da clonare, facendo la fortuno dei vari produttori di compiter "PC (IBM) compatibili" e questo favorì la diffusione del software sviluppato appositamente, facendo da ulteriore volano per lo sviluppo di software "aziendale" per esso e si creò quell'ecosistema software che ha fatto le fortune di Intel e di Microsoft (ma paradossalmente altrettanto per IBM, che ad un certo punto pensò di essere lei ad "avere il controllo" e per questo perse parecchio terreno e per sopravvivere fu smembrata e ridimensionata in vari modi).

[LMCH]

Originariamente inviato da gilles17871

Sostanzialmente ha ragione, ma per far rendere bene l'architettura arm bisogna scrivere codice altamente ottimizzato (si ci sono i compilatori, ma non fanno miracoli).
Le architetture x86 da sempre sono state in grado di digerire codice fatto con i piedi e le implementazioni di nuove istruzioni servono anche a rendere più efficente il codice semplificandolo.

Scusa, ma mi sa che non sia chiaro che per avere prestazioni "migliori" facendo girare codice binario preesistente le cpu x86 fin che è stato possibile, sono salite di clock aumentando i consumi e poi a colpi di incrementi della complessità di implementazione (numero di transistor da dedicare all'implementazione di logica di scheduling, reordering e microparallelismo) aumentando consumi, area del chip e costo.

Proprio a causa del crescere dellle prestazioni delle cpu x86 molto codice per esse è scritto pensando decisamente poco a spremerle al meglio (il ragionamento era: tanto tra un anno le cpu in commercio saranno più veloci, quindi se ora gira decentemente non serve ottimizzare oltre).

Poi riguardo i compilatori, anche quelli per ARM applicano ottimizzazioni parecchio sofisticate, non sta certo li un ipotetico "vantaggio" degli x86.

Il vero problema degli x86 è che hanno si una mole enorme di codice già sviluppato per essi, ma è quasi tutto pensato per girare su cpu-stufetta con uno schermo da (preferibilmente) 15 pollici o più, tastiera e mouse su Windows con UI WIMP.
Quindi il "vecchio" codice non gira così bene su dispositivi embedded, le loro prestazioni in rapporto al consumo non sono così competitive ed Intel abituata ad un monopolio di fatto non ha ancora recepito interiormente che ora ha un fottio di concorrenti agguerriti ed un fottio di fascie di mercato da coprire.

Poi un altro fattore da non trascurare è il passato di Intel stessa.

Sebbene per un certo periodo fosse stata la produttrice delle cpu ARM incontestabilmente più potenti (gli StrongARM e gli XScale), Intel è stata capace di perdere la leadership con le sue stesse mani (non prestando sufficiente attenzione a quello che volevano i produttori di dispositivi) ed era pure uscita completamente dal settore.

Nel settore degli x86 poi non appena ha ottenuto un quasi-monopolio ha strizzato per bene i produttori, mentre scegliendo ARM i produttori mitigano enormemente tale rischio visto che si più scegliere tra più fornitori e passare da uno all'altro se necessario o anche "farsi produrre il SoC su ordinazione".

[gilles17871]

Originariamente inviato da LMCH

Scusa, ma mi sa che non sia chiaro che per avere prestazioni "migliori" facendo girare codice binario preesistente le cpu x86 fin che è stato possibile, sono salite di clock aumentando i consumi e poi a colpi di incrementi della complessità di implementazione (numero di transistor da dedicare all'implementazione di logica di scheduling, reordering e microparallelismo) aumentando consumi, area del chip e costo.

Proprio a causa del crescere dellle prestazioni delle cpu x86 molto codice per esse è scritto pensando decisamente poco a spremerle al meglio (il ragionamento era: tanto tra un anno le cpu in commercio saranno più veloci, quindi se ora gira decentemente non serve ottimizzare oltre).

Poi riguardo i compilatori, anche quelli per ARM applicano ottimizzazioni parecchio sofisticate, non sta certo li un ipotetico "vantaggio" degli x86.

Il vero problema degli x86 è che hanno si una mole enorme di codice già sviluppato per essi, ma è quasi tutto pensato per girare su cpu-stufetta con uno schermo da (preferibilmente) 15 pollici o più, tastiera e mouse su Windows con UI WIMP.
Quindi il "vecchio" codice non gira così bene su dispositivi embedded, le loro prestazioni in rapporto al consumo non sono così competitive ed Intel abituata ad un monopolio di fatto non ha ancora recepito interiormente che ora ha un fottio di concorrenti agguerriti ed un fottio di fascie di mercato da coprire.

Poi un altro fattore da non trascurare è il passato di Intel stessa.

Sebbene per un certo periodo fosse stata la produttrice delle cpu ARM incontestabilmente più potenti (gli StrongARM e gli XScale), Intel è stata capace di perdere la leadership con le sue stesse mani (non prestando sufficiente attenzione a quello che volevano i produttori di dispositivi) ed era pure uscita completamente dal settore.

Nel settore degli x86 poi non appena ha ottenuto un quasi-monopolio ha strizzato per bene i produttori, mentre scegliendo ARM i produttori mitigano enormemente tale rischio visto che si più scegliere tra più fornitori e passare da uno all'altro se necessario o anche "farsi produrre il SoC su ordinazione".

Fintando che si usa software non troppo complesso l'architettura arm ha una maggiore effecenza (e non ci piove).
Ma quando si devono svolgere compiti più complessi arm mostra i propri limiti nel non poter gestire salti efficacemente e nel dover utilizzare + ram per caricare il software da eseguire.
Vero è che molti miglioramemti ci sono stati per mitigare questi difetti, ma resta sempre il fatto che per codice complesso (o anche per molte istanze di th simultanee) arm perde molto (anche in fatto di efficenza) rispetto ad x86.
Bene ad oggi non sembra importante, ma gia ci rendiamo conto delle limitazioni quando si tratta di programmi in background che vengono "congelati" per liberare memoria e cicli macchina nel gestire la stessa.
X86 ha molti meno problemi da questo punto di vista, ed oltre un certo limite di carico ha anche una maggior efficenza energetica (basta vedere confronti Arm vs xeon su server reperibili in rete).
Se una cpu arm ad oggi va bene per dispositivi come smartphone e tablet non è detto che domani lo sia ancora per i tablet, se come è vero dovrebbero andare a sostituire i notebook e desktop di fascia bassa.
riguardo la politica commerciale del non volersi legare ad un fornitore tirannico come intel da parte delle aziende (forse domani potrebbe riuscire anche AMD a fare soc a bassissimo consumo) hai perfettamente ragione, e credo che questa sia l'unica limitazione reale presente ad oggi nell'adottare o meno queste cpu nei tablet.

[calabar]

Originariamente inviato da gilles17871

Fintando che si usa software non troppo complesso l'architettura arm ha una maggiore efficienza (e non ci piove).

Hai qualche fonte affidabile a conferma di questa affermazione?

Potrebbe essere un discorso interessante, ma francamente questa divisione tra software semplice e complesso mi sembra decisamente poco fondata, il codice si riduce sempre ad operazioni "semplici" da dare in pasto all'hardware, con un'unità di misura molto inferiore alla complessità di qualsiasi software.

[gilles17871]

Originariamente inviato da calabar

Hai qualche fonte affidabile a conferma di questa affermazione?

Potrebbe essere un discorso interessante, ma francamente questa divisione tra software semplice e complesso mi sembra decisamente poco fondata, il codice si riduce sempre ad operazioni "semplici" da dare in pasto all'hardware, con un'unità di misura molto inferiore alla complessità di qualsiasi software.

Arm è un'architettura di tipo risc ed accetta istruzioni semplici (o ridotte ai minimi termini).
X86 è un'architettura Cisc (anche se le moderne x86 sono ibride con front-end cisc che trasforma o traduce le macro ops in risc da dare in pasto alle unità di elaborazione) ed accetta istruzioni complesse che vengono trasformate in semplice all'interno della cpu.
Va da se che l'obbligo di utilizzare istruzioni a lunghezza fissa (32 o 64 bit) impone un utilizzo maggiore di ram da parte del codice, cosa che invece con cisc viene molto limitata.
Questa caratteristica di cisc ha portato a definirla un'architettura poco efficente (a causa della complessità richiesta dall'architettura), ma sfido chiunque a scrivere codice arm (o propriamente risc) in grado di avere la stessa efficenza energetica che si hanno con istruzioni sse o avx nelle moderne cpu (per non parlare di crittografia).
Dunque se vogliamo considerare un tablet l'estensione di uno smartphone arm è ok, ma se, come effettivamente sembra, questa tipologia di prodotti è destinata a sostituire pc e notebook non credo che arm abbia la stessa efficenza di x86 (tralasciando la retrocompatibilità) su elevati carichi.
Scrivere da zero un software per arm, o scriverlo per x86 non è uguale ed utilizzando le ottimizzazioni di x86 (per codice exnovo, al pari di arm) ci ritrovereme con un'architettura si con il doppio di transistor, ma che richiede un quarto di energia per eseguire lo stesso compito.

[calabar]

@gilles17871
Quello che scrivi è per certi versi corretto, ma non ha nulla a che vedere con la complessità del software.

Io posso creare un software semplicissimo che sfrutta la FPU (AVX, SSE, ecc... sono tutti set di istruzioni per la FPU), così come uno estremamente complesso basato solo sull'uso delle unità intere.

Oltretutto questi SOC accelerano gran parte delle operazioni tramite la GPU integrata, il che per certi versi equivale all'uso della FPU (non proprio a dire il vero, ma sono parenti stretti... lo dimostra per esempio il fatto che le ultime architettura AMD stiano sempre più sacrificando la FPU tradizionale per sostituirla con elementi della GPU, il progetto HSA).

Non saprei dirti come sono messi gli attuali SOC ARM a livello di FPU e la lunghezza delle istruzioni ARMv#, ma il fatto di essere RISC o CISC conta ben poco, sono solo due approcci differenti. Oltretutto come tu stesso dici, gli attuali x86 non sono CISC, sono RISC con un layer di traduzione delle istruzioni complesse, operazione che può essere fatta anche in fase di compilazione.

[PaulGuru]

Originariamente inviato da calabar

Hai qualche fonte affidabile a conferma di questa affermazione?

Potrebbe essere un discorso interessante, ma francamente questa divisione tra software semplice e complesso mi sembra decisamente poco fondata, il codice si riduce sempre ad operazioni "semplici" da dare in pasto all'hardware, con un'unità di misura molto inferiore alla complessità di qualsiasi software.

Scusa Calabar ma se è per questo non esistono nemmeno test adeguati ad una comparazione per poter contraddire la cosa.

[gilles17871]

Originariamente inviato da calabar

@gilles17871
Quello che scrivi è per certi versi corretto, ma non ha nulla a che vedere con la complessità del software.

Io posso creare un software semplicissimo che sfrutta la FPU (AVX, SSE, ecc... sono tutti set di istruzioni per la FPU), così come uno estremamente complesso basato solo sull'uso delle unità intere.

Oltretutto questi SOC accelerano gran parte delle operazioni tramite la GPU integrata, il che per certi versi equivale all'uso della FPU (non proprio a dire il vero, ma sono parenti stretti... lo dimostra per esempio il fatto che le ultime architettura AMD stiano sempre più sacrificando la FPU tradizionale per sostituirla con elementi della GPU, il progetto HSA).

Non saprei dirti come sono messi gli attuali SOC ARM a livello di FPU e la lunghezza delle istruzioni ARMv#, ma il fatto di essere RISC o CISC conta ben poco, sono solo due approcci differenti. Oltretutto come tu stesso dici, gli attuali x86 non sono CISC, sono RISC con un layer di traduzione delle istruzioni complesse, operazione che può essere fatta anche in fase di compilazione.

Credo di essermi spiegato male:
Immaginiamo istruzione di dover eseguire una moltiplicazione (non è questo il caso, ma solo per semplificare):
compilatole x86 > Cisc 10 X 10 > front end cpu <> 10 +10 +10 +10 +10 +10 ecc
Compilatore risc > risc 10 +10 +10 +10 ecc> cpu.
Come vedi l'occupazione del codice in ram per essere eseguito è di diverse grandezze inferiore in ram nel caso di cpu cisc (ipotizzando la stessa velocità di esecuzione, anche se non è vero).
Io parlavo di questo.
Oltretutto la parte fpu in arm è di diversi ordini di grandezza inferiore a x86 (è da vedere se per semplificazioni architetturali o per limiti intrinsechi).
Va da se che implementazioni software (come la crittografia dei dati indispensabile in un dispositivo mobile tuttofare) diviene un poco ostico da eseguire su cpu arm (ok possono sempre integrare un chip dedicato nel soc).
Quindi fin tanto che un tablet è inteso come dispositivo di fruizione arm va bene (è facile implementare funzionalità standard di decodifica e/o operazioni semplici sia in hardware che software), ma se vogliamo farne un dispositivo idoneo anche per la creazione vedo (al momento attuale) in arm non il candito ideale.
Fermo restando che l'opinione di LMCH riguardo Intel fagocita-tutto la condivido e sottoscrivo.
Poi abbiamo visto che la migliore soluzione tecnica spesso non lo è commercialmente.

[calabar]

Originariamente inviato da PaulGuru

Scusa Calabar ma se è per questo non esistono nemmeno test adeguati ad una comparazione per poter contraddire la cosa.

Solitamente quando uno fa un'affermazione, sta a lui dimostrarne la fondatezza.

Originariamente inviato da gilles17871

Credo di essermi spiegato male:
Immaginiamo istruzione di dover eseguire una moltiplicazione (non è questo il caso, ma solo per semplificare): [...]

Effettivamente non avevo colto esattamente il punto. Ma del resto se fosse solo un discorso di questo tipo, un certo overhead sulla ram potrebbe essere sopportabile.
Oltretutto facendo uso di un numero minore di simboli (nel tuo esempio il processore x86 ha "+" e "x", mentre l'arm ha solo "+"), è possibile risparmiare RAM perchè si fa uso di una codifica più leggera (meno simboli, meno bit). E questo riequilibra un po' le cose.

[gilles17871]

Originariamente inviato da calabar

Effettivamente non avevo colto esattamente il punto. Ma del resto se fosse solo un discorso di questo tipo, un certo overhead sulla ram potrebbe essere sopportabile.
Oltretutto facendo uso di un numero minore di simboli (nel tuo esempio il processore x86 ha "+" e "x", mentre l'arm ha solo "+"), è possibile risparmiare RAM perchè si fa uso di una codifica più leggera (meno simboli, meno bit). E questo riequilibra un po' le cose.

Quello dell'overhead in ram è una parte del limite risc (ed arm di conseguenza)
In link puoi capire meglio quello che cerco di dire (sopratutto riguardo la complessità del codice)
In particolare :

If one of the operands needs to be used for another computation, the processor must re-load the data from the memory bank into a register. In RISC, the operand will remain in the register until another value is loaded in its place.

Dove si può dedurre che con codice "semplice" lo svantaggio teorico di risc sia pareggiato dal possibile riutilizzo di dati caricati nel registro, ma quando il codice è complesso (o "grande") i registri vengono esauriti e sovrascritti prima che questo vantaggio possa concretizzarsi.
Da qua il principio che esponevo riguardo i "miracoli" che non possono fare i compilatori per Arm ed il principio per il quale costa maggiori risorse scrivere codice complesso su arm rispetto la relativa facilità nel poter utilizzare funzioni specifiche (le estensioni delle quali parlavo) su architettura cisc con il vantaggio di non dover necessariamente affidarsi ad un fine tunning del codice da dare in pasto al compilatore.
Poi felice di avere chiarimenti (l'architettura logica delle cpu non è il mio forte) in merito a quello che ho esposto.
Spero di essere stato (nei miei limiti) chiaro.

[LMCH]

Originariamente inviato da gilles17871

Fintando che si usa software non troppo complesso l'architettura arm ha una maggiore effecenza (e non ci piove).

L'efficienza di una specifica implementazione di un architettura E' INDIPENDENTE dalla complessità del software che esegue.

Sia che si esegua software "semplice" che "complesso", l'efficienza dell'hardware di per se non cambia, semmai e' l'efficienza di implementazione del software a variare a parità di cpu.

Originariamente inviato da gilles17871

Ma quando si devono svolgere compiti più complessi arm mostra i propri limiti nel non poter gestire salti efficacemente e nel dover utilizzare + ram per caricare il software da eseguire.

Set d'istruzioni ed implementazione hardware sono due cose distinte.

A livello di set d'istruzioni gli ARM sono stati sin dal principio MOLTO più efficienti degli x86 nell'eseguire i salti (perchè permettevano di usare l'esecuzione condizionale al posto di salti "brevi"), ovverosia permettono di avere prestazioni superiori senza gravare l'implementazione hardware con logica e scheduling di predizione dei salti condizionali.

Gli x86 non avevano tale possibilità (solo con i Pentium furono aggiunte le MOV condizionali) e quindi per essi è praticamente obbligatorio implementarli con la circuiteria di predizioni dei salti se si vogliono tener alte le prestazioni.

Ma ovviamente anche nell'implementazione di un architettura ARM si può aggiungere la predizione dei salti se si ritiene che ne valga la pena, non è una cosa che hanno solo gli x86.

Per rendere l'idea, i Cortex A8 non hanno la jump prediction, mentre i Cortex A9 si anche se è relativamente semplice (il solito discorso che non è necessario spingere su circuiteria complessa che aumenti i consumi se hai già un buon set'istruzioni che ti semplifica le cose e le prestazioni sono già sufficienti per le applicazioni per cui è previsto l'utilizzo di quel chip).

Anche per quel che riguarda il consumo di memoria le cose non sono così semplici come hai scritto:
- inizialmente le istruzioni x86 erano più "compatte" ma per fare la stessa cosa richiedevano un maggior numero di istruzioni per fare la stessa cosa che su un ARM richiede un unica istruzione;
- poi generazione di cpu dopo generazione, a forza di estensioni alcune istruzioni x86 che corrispondono ad una singola istruzione ARM ... risultano avere più o meno la stessa occupazione di memoria ... e restano più complesse da decodificare;
- anche il set d'istruzioni degli ARM non è rimasto immutato; proprio perchè sono usatissimi in applicazioni embedded (dove meno memoria si usa e meglio è) furono introdotte le estensioni THUMB e THUMB2 che permettono di ridurre la memoria utilizzata dal codice (ed il traffico dati da/verso la memoria esterna) e poi le estensioni NEON ecc. che aggiungono funzionalità VLIW analoghe ad SSE ed AVX degli x86 (N.B. analoghe, ma pensate tenendo conto di "cosa serve" davvero in ambito embedded e mobile, mica su desktop).

Originariamente inviato da gilles17871

Vero è che molti miglioramemti ci sono stati per mitigare questi difetti, ma resta sempre il fatto che per codice complesso (o anche per molte istanze di th simultanee) arm perde molto (anche in fatto di efficenza) rispetto ad x86.

Questo se si ignorano totalmente le condizioni al contorno tipo ampiezza del bus con la ram, dimensioni delle cache, massima potenza dissipabile, ecc.

Intel ha speso più di 20 anni per far girare meglio il codice x86 su cpu desktop mitigandone i difetti intrinsechi in ogni modo possibile (ma che comportava maggiori consumi, maggior area utilizzata sul chip a scapito di altre cose e pure limitazioni sul massimo clock raggiungibile a causa dell'aumento della complessità di implementazione e dei ritardi di propagazione dei segnali all'interno del core).

ARM Ltd è partita da un architettura già molto buona, l'ha resa più efficiente in termini di utilizzo in ambito embedded e dove serviva ha alzato le prestazioni senza dover usare tutto l'arsenale di barbatrucchi implementativi che invece è necessario per cpu con set d'istruzioni x86
(proprio perchè non erano progettati per desktop e server, ma per roba embedded).

Nel momento in cui qualcuno deciderà sul serio di "spingere al massimo le prestazioni degli ARM" (accettando i maggiori consumi ed il maggior utilizzo di area utile sul chip che per un x86 per desktop/server è "normale") non mi stupirei se gli x86 venissero sorpassati anche in tale ambito.

Originariamente inviato da gilles17871

Bene ad oggi non sembra importante, ma gia ci rendiamo conto delle limitazioni quando si tratta di programmi in background che vengono "congelati" per liberare memoria e cicli macchina nel gestire la stessa.

Quello di cui parli sopra dipende dal S.O. e dall'applicazione che ci gira sopra, più che dall'architettura del processore utilizzato.

Originariamente inviato da gilles17871

X86 ha molti meno problemi da questo punto di vista, ed oltre un certo limite di carico ha anche una maggior efficenza energetica (basta vedere confronti Arm vs xeon su server reperibili in rete).

Hai almeno vagamente presente cosa sono gli Xeon ?
Di solito quando si fa un affermazione del genere è consigliabile fornire link validi con dati credibili a suo supporto, perchè ... diciamo che solleva qualche perplessità.

Originariamente inviato da gilles17871

Se una cpu arm ad oggi va bene per dispositivi come smartphone e tablet non è detto che domani lo sia ancora per i tablet, se come è vero dovrebbero andare a sostituire i notebook e desktop di fascia bassa.

Dal lato hardware si tratterebbe solo di sviluppare un implementazione ottimizzata per notebook e desktop (ovvero: progettata per dare maggiori prestazioni in termini di capacità di calcolo anche se questo comporta consumi superiori e maggior area del chip).

Ma come già detto in precedenza, quello che conta è il software, per ora il software "che fa vendere l'hardware" per desktop e notebook richiede una cpu x86.
Quindi avrebbe poco senso cercare di sfondare li (per ora) anche se per certe applicazioni potrebbe aver senso.
Ad esempio la ditta per cui lavoro attualmente propone anche fronted basati su tablet Android per cose per cui in precedenza venivano proposti solo frontend basati su pc x86.

Ma per i server "infrastrutturali" e "da grande azienda" la cosa è differente, visto che spesso non usano neanche Windows e si basano su software crossplatform oppure relativamente facile da portare su ARM (se non lo è già).
Ovviamente da questo per ora sono esclusi i server che usano Windows, ma l'esistenza di Windows RT (che "sotto il cofano" supporta ancora modalità desktop e le "vecchie" API Win32) fa pensare che Microsoft abbia qualcosa da proporre in tal senso nel caso ARM inizi lo sfondamento sul lato server.