Link alla notizia: http://www.hwupgrade.it/news/tablet/intel-bay-trail-e-piu-potente-ed-efficiente-di-apple-a7_49226.html

Il CEO di Brian Krzanich ha palesato la superiorità dei chip Intel rispetto al nuovissimo A7 di Apple in una nuova intervista

Click sul link per visualizzare la notizia.

ma è proprio questo il bello... se veramente Intel Bay Trail fosse più veloce e prestante di A7 persino con IOS 7...
Il prossimo iPhone 6 potrebbe montarlo senza problemi... i sistemi Android e Apple Os sono multi-piattaforma...

Non è che tutto questo HIPE ha proprio questo scopo..? un messaggio ad Apple del tipo ... :

"anzichè farti fare i nuovi A8 da qualche fonderia Taiwanese (dato che con Samsung siate alla canna del gas).. prendi i nostri... guarda che bombe..! e sono pure U.S.A..!"

perchè no? a me intrigano molto! volevo prendere un Lenovo con la vecchia versione Atom per provarli!

@Cappej
Perchè? Nel caso di Apple secondo me i motivi possono essere diversi:
- Potere contrattuale e costi. Intel non è mai stata economica, e dubito che Apple possa contrattare un prezzo come quello che ottiene dai fornitori attuali.
- Ottimizzazione. Quando fai il chip per conto tuo, puoi introdurre a tuo piacimento nuove funzionalità e costruire il software su quelle.
- Costi di conversione del software. iOS nasce e vive su processori ARM, la conversione e l'ottimizzazione per gli Atom richiederebbe risorse.
- Vincoli. x86 è un'architettura con pochi licenziatari, uno solo dei quali, Intel, offre prodotti adeguati. Se cominci a legarti ad Intel, rischi di non uscirne più anche se vorresti, se non pagandone un costo elevato. Inoltre saresti sempre vincolato alle scelte e le tempistiche di Intel.
- Chi fa una scelta del genere ragiona sempre a lungo termine, e non è detto che questa supremazia sui processi produttivi duri per sempre.

Insomma, a meno che non cominci ad esserci una supremazia tecnologia netta, come quella che portò Apple al passaggio agli x86 con i MAC, non ha senso impelagarsi in una scelta del genere.

viva la concorrenza.. cosi magari vedremo degli apple veramente performanti a prezzi livellati enon puri esercizi di stile al 500% del loro reale valore per giustificare l'acquisto degli sfigati di turno..

@calabar
Discorso di grande buon senso, condivido ogni parola.

Di sicuro questa piattaforma bay trail è interessantissima, soprattutto per avere FINALMENTE tablet a prezzi umani con Windows 8.1 x86/x64 e mandare definitivamente in pensione quell'aborto di Windows RT!

capirai poi sentiremo orde di fanboy " io ho il mio NUOVO iphone con processore intel mica quello schifo di arm!"

Dubito che Apple vorrà abbandonare ARM per le x86-x64 nel breve periodo. Certamente intel è un partner che significa qualità, ma bisognerà aspettare ancora.

Solo una cosa non ha detto: che x86 usa(va) circa 10 volte il numero di transistor di ARM

Solo una cosa non ha detto: che x86 usa(va) circa 10 volte il numero di transistor di ARM

E' irrilevante.
quello che conta in tecnologia e informaticaè il risultato e il costo del prodotto, se è competitivo come questo si è raggiunto alla fine non importa a nessuno in nessun campo.

E' irrilevante.
quello che conta in tecnologia e informaticaè il risultato e il costo del prodotto, se è competitivo come questo si è raggiunto alla fine non importa a nessuno in nessun campo.

E i fanboy??? :sofico:

E' irrilevante.
quello che conta in tecnologia e informaticaè il risultato e il costo del prodotto, se è competitivo come questo si è raggiunto alla fine non importa a nessuno in nessun campo.
E' rilevantissimo invece, perché il numero dei transistor e il processo produttivo definiscono quale sia il costo del chip che vai a produrre.
Il processo produttivo a 22nm è più costoso di quella a 28nm. Se poi anche con la miniaturizzazione arrivi ad avere un die grande il doppio, il costo è superiore.
Infatti l'omino Intel parla di (ovvia) densità superiore garantita dal processo produttivo, non della dimensione del die.

Il tutto senza contare che Intel ha sempre e solo usato un'architettura monolotica "ALU centrica", mentre i SoC ARM sono un insieme di processori che gesticono ciascuno un determinato tipo di lavoro. E l'ISA ARM è pensata per sfruttare qualsiasi componente esterno. Questo vuol dire che se domani Apple vuole aggiungere per esempio un mega DSP (e/o altri componenti di calcolo) per fare gestire Siri in locale lo può fare. Con Intel deve sperare che li integri. E se lo fa che siano potente a sufficienza e non incidano come decide Intel sul prezzo finale.

Si ma qui si stanno paragonando le mele (A7) con le pere (Bay Trail) e poi si annuncia che in futuro (!) ci sarà qualcosa (Moorefield e Cherry Trail) che competerà con l'A7 già presente.

Se ha il doppio dei transistor e consuma la metà, è meglio.

viva la concorrenza.. cosi magari vedremo degli apple veramente performanti a prezzi livellati enon puri esercizi di stile al 500% del loro reale valore per giustificare l'acquisto degli sfigati di turno..

Ma è davvero inevitabile il commentino acido da bambino dell' asilo ogni volta che che viene in qualche modo nominata Apple ? Se c'è qualcosa da sfigati qui è l' irrefrenabile ed irrinunciabile necessità di mandare in vacca un thread dando sfogo alle proprie ingiustificabili frustrazioni.

Nel mondo dei bimbigrandi se non condividi qualcosa non lo compri ;).

viva la concorrenza.. cosi magari vedremo degli apple veramente performanti a prezzi livellati enon puri esercizi di stile al 500% del loro reale valore per giustificare l'acquisto degli sfigati di turno..

addio

eeeh anche secondo me c'entra poco o niente come paragone...

ne traggo che intel voglia mettere l'accento su quanto si stia concentrando su consumi e processo produttivo, ma è un accostamento infelice - in comune han solo la destinazione tablet/mobile

Se ha il doppio dei transistor e consuma la metà, è meglio.
Ni. Correggerei in: se hai il doppio dei transistor, consumi la metà e hai le stesse prestazioni e sei rivolto ad un mercato che ha priorità sui consumi allora è meglio.
Il doppio dei transistor vuol dire maggior area, maggiori costi in die o in processi produttivi necessari per ridurla.
A partià di processo produttivo il doppio dei transistor significa il doppio dei consumi.
Se conti di vivere solo ed esclusivemente sul vantaggio del processo produttivo e di pagartelo riuscendo a mantenere un guadagno sufficiente allora puoi credere che una architettura del genere possa avere futuro.
Altrimenti diventa un problema quando i costi del nuovo processo produttivo diventano elevati e non vendi a sufficienza per compensare quello che ti serve per investire in uno nuovo.
Intel è in posizione critica in questo momento. I 14nm li ha pagati molto cari, 6 miliardi in più del previsto (che non vuol dire 6 miliardi in totale, ma in più), ha qualche mese di ritardo e i suoi nuovi prodotti necessitano di quel processo per essere competitivi con chi oggi ancora produce a 28nm che è un processo maturo e dal costo relativamente basso (sicuramente minore dei 14nm). Se ti mangi il vantaggio della maggiore densità (e quindi in teoria meno spazio sul die) con una architettura che occupa il doppio o il quadruplo, significa che alla fine il tuo prodotto costa di più (stessa area ma realizzato con un processo produttivo più costoso, di cui hai pagato anche la ricerca e sviluppo e che dovrà comunuqe garantire sufficiente introiti per quello successivo).

Non è un caso che Intel è da un paio di anni che annuncia continuamente prodotti futuri che devono andare in concorrenza con alcuni sul mercato già da tempo. Ogni volta dice che uscirà qualcosa di meglio.
Normalmente uno che ha fiducia in un proprio prodotto non dice che entro tot mesi ne verrà proposto uno migliore (in teoria è scontato senza dover dichiarare la data di rilascio). E ogni volta ovviamente fallisce perché crede che gli altri rimangano a guardare o spera che l'evoluzione degli altri sia molto più lenta della propria.

Questa volta forse ce la fa, con TSMC e il suo processo produttico a 20nm in alto mare e GF che non ha un piano di rinnovamento ancora più lungo.
Il problema è se il vantaggio che finalmente è riuscita a ottenere, permetterà ad Intel di incamerare a sufficienza per mantenere questo vantaggio. La produzione di SoC per mobile è notoriamente una attività che rende poco se non si vendono enormi quantità di chippettini. Non mi sembra che Intel sia in quella posizione. Apple vende più chip ARM di quanti processori x86 (tutti) Intel venda ogni anno.
E Apple (come Qualcomm) non deve pagare lo sviluppo di alcun nuovo processo produttivo per rimanere competitiva.
Che +è un vantaggio non da poco anche quando le fabbriche sono in ritardo (mentre per Intel sono dolori).

Ni. Correggerei in: se hai il doppio dei transistor, consumi la metà e hai le stesse prestazioni e sei rivolto ad un mercato che ha priorità sui consumi allora è meglio.
Il doppio dei transistor vuol dire maggior area, maggiori costi in die o in processi produttivi necessari per ridurla.
A partià di processo produttivo il doppio dei transistor significa il doppio dei consumi.
Se conti di vivere solo ed esclusivemente sul vantaggio del processo produttivo e di pagartelo riuscendo a mantenere un guadagno sufficiente allora puoi credere che una architettura del genere possa avere futuro.
Altrimenti diventa un problema quando i costi del nuovo processo produttivo diventano elevati e non vendi a sufficienza per compensare quello che ti serve per investire in uno nuovo.
Intel è in posizione critica in questo momento. I 14nm li ha pagati molto cari, 6 miliardi in più del previsto (che non vuol dire 6 miliardi in totale, ma in più), ha qualche mese di ritardo e i suoi nuovi prodotti necessitano di quel processo per essere competitivi con chi oggi ancora produce a 28nm che è un processo maturo e dal costo relativamente basso (sicuramente minore dei 14nm). Se ti mangi il vantaggio della maggiore densità (e quindi in teoria meno spazio sul die) con una architettura che occupa il doppio o il quadruplo, significa che alla fine il tuo prodotto costa di più (stessa area ma realizzato con un processo produttivo più costoso, di cui hai pagato anche la ricerca e sviluppo e che dovrà comunuqe garantire sufficiente introiti per quello successivo).

Non è un caso che Intel è da un paio di anni che annuncia continuamente prodotti futuri che devono andare in concorrenza con alcuni sul mercato già da tempo. Ogni volta dice che uscirà qualcosa di meglio.
Normalmente uno che ha fiducia in un proprio prodotto non dice che entro tot mesi ne verrà proposto uno migliore (in teoria è scontato senza dover dichiarare la data di rilascio). E ogni volta ovviamente fallisce perché crede che gli altri rimangano a guardare o spera che l'evoluzione degli altri sia molto più lenta della propria.

Questa volta forse ce la fa, con TSMC e il suo processo produttico a 20nm in alto mare e GF che non ha un piano di rinnovamento ancora più lungo.
Il problema è se il vantaggio che finalmente è riuscita a ottenere, permetterà ad Intel di incamerare a sufficienza per mantenere questo vantaggio. La produzione di SoC per mobile è notoriamente una attività che rende poco se non si vendono enormi quantità di chippettini. Non mi sembra che Intel sia in quella posizione. Apple vende più chip ARM di quanti processori x86 (tutti) Intel venda ogni anno.
E Apple (come Qualcomm) non deve pagare lo sviluppo di alcun nuovo processo produttivo per rimanere competitiva.
Che +è un vantaggio non da poco anche quando le fabbriche sono in ritardo (mentre per Intel sono dolori).
Hai perfettamente ragione quando trattiamo lo stesso processo produttivo.
Bisogna capire però che il processo produttivo è molto differente da fab a fab,
per i chip ad alte prestazioni vedo in vantaggio global foundry lato costi di sviluppo e costo del singolo chip rispetto ad intel, bisogna capire prima di parlare di costi di sviluppo e del singolo chip se i costi sono uguali (a parità di pp e superfice) tra intel e le fab che producono soc arm.
Magari si scopre che i chip intel costano produrli molto meno che quelli tsmc ed allora tutta l'equazione numero di transistor, efficenza energetica, costo a mm2 andrebbe rivista.
Fermo restando il tuo discorso più che giusto preferisco aggiungerci questa incognita.

E' rilevantissimo invece, perché il numero dei transistor e il processo produttivo definiscono quale sia il costo del chip che vai a produrre.
Il processo produttivo a 22nm è più costoso di quella a 28nm. Se poi anche con la miniaturizzazione arrivi ad avere un die grande il doppio, il costo è superiore.
Infatti l'omino Intel parla di (ovvia) densità superiore garantita dal processo produttivo, non della dimensione del die.

Il tutto senza contare che Intel ha sempre e solo usato un'architettura monolotica "ALU centrica", mentre i SoC ARM sono un insieme di processori che gesticono ciascuno un determinato tipo di lavoro. E l'ISA ARM è pensata per sfruttare qualsiasi componente esterno. Questo vuol dire che se domani Apple vuole aggiungere per esempio un mega DSP (e/o altri componenti di calcolo) per fare gestire Siri in locale lo può fare. Con Intel deve sperare che li integri. E se lo fa che siano potente a sufficienza e non incidano come decide Intel sul prezzo finale.


Sono pienamente d'accordo con te ed è vero molte persone non capiscono questo discorso.
Adesso capisco perchè Intel non riesca ad entrare nel mercato nonostante sia più di 1 anno che fa ottimi prodotti: evidentemente costano di più!!!
E aggiungo: secondo me Intel sta vendendo sottocosto ottimi prodotti ma nonostante tutto non riesce a sfondare.
Cara Intel stavolta non ti riesce il giochetto che hai fatto con AMD! E passando ai 14nm ci sarà si un migliramento notevole della prestazione ma poi riesci a vendere ad un prezzo competitivo? Occhio che ci vuole un attimo a fare la fine di Nokia...

Tutti questi discorsi su dimensioni, numero di transistor, processi produttivi, consumi e performance hanno senso finchè si paragonano le stesse architetture. Con architetture diverse tutto va a farsi benedire.

@diabolikum
No, contano a prescindere dall'architettura, perchè parliamo di costi.

@CrapaDiLegno
Mi fa piacere di non essere l'unico a notare le difficoltà di Intel con i nuovi processi produttivi e gli enormi investimenti che ha fatto per arrivare "quasi" per tempo con i suoi 14nm.
A mio parere questo sarà il massimo vantaggio di Intel da questo punto di vista ma è destinato a ridursi a meno che non accada qualcosa di davvero nuovo.
I processi FD-SOI su cui stanno puntando le altre fonderie sono più adatti alla miniaturizzazione di quelli Intel e se non si incappa in qualche problema imprevisto, dovrebbero permettere di ridurre il gap con spese più contenute.
Tenete poi conto dell'enorme quantità di denaro che sta girando intorno alle altre fonderie per via del boom del mercato mobile e capirete che questa situazione potrebbe non durare.
Non è la qualità dei transistor Intel ad essere messa in discussione, ma il loro costo e la sostenibilità di tutto questo.

@CrapaDiLegno
Mi fa piacere di non essere l'unico a notare le difficoltà di Intel con i nuovi processi produttivi e gli enormi investimenti che ha fatto per arrivare "quasi" per tempo con i suoi 14nm.
A mio parere questo sarà il massimo vantaggio di Intel da questo punto di vista ma è destinato a ridursi a meno che non accada qualcosa di davvero nuovo.
I processi FD-SOI su cui stanno puntando le altre fonderie sono più adatti alla miniaturizzazione di quelli Intel e se non si incappa in qualche problema imprevisto, dovrebbero permettere di ridurre il gap con spese più contenute.
Tenete poi conto dell'enorme quantità di denaro che sta girando intorno alle altre fonderie per via del boom del mercato mobile e capirete che questa situazione potrebbe non durare.
Non è la qualità dei transistor Intel ad essere messa in discussione, ma il loro costo e la sostenibilità di tutto questo.
Questo è un interrogativo, ma credo piuttosto che intel nella riduzione dei consumi abbia fatto miracoli (e quest'architettura lo dimostra).
Bisogna vedere se fd-soi riuscirà a portare un basso consumo relativamente alle prestazioni su architettura arm, anche se ad oggi mi sembra poco propenso a mantenere queste promesse.
Dal lato intel gia mi venivano dubbi sui 32nm e praticamente da allora abbiamo avuto miglioramenti prestazionali dovuti ad affinamenti dell'architettura, piuttosto che dall'aumento di freq o numero transistor, ma al contempo abbiamo visto come i consumi abbiano fatto passi da givante ed addirittura gli atom hanno raddoppiato le prestazioni (passando dall'in-order all'out-of-order, piu esoso in termini energetici) abbassando al contempo i consumi per ipc rapportati pur anche ai pp.
Dal lato fd-soi non posso esprimermi, ma se mantiene la caratteristica di voler voltaggi leggermente superiori al bulk intel come vediamo nel soi attuale sarà una battaglia molto incerta.

Se parliamo di costi, con Atom BTrail è possibile avere tablet a 299$ al lancio, quindi direi che anche a livello di costi sono ottimi, se si considera che tablet con Snapdragon 800 hanno costi molto più elevati.

Se parliamo di costi, con Atom BTrail è possibile avere tablet a 299$ al lancio, quindi direi che anche a livello di costi sono ottimi, se si considera che tablet con Snapdragon 800 hanno costi molto più elevati.
Veramente non possiamo dire nulla:
se un snapdragon 800 costa produrlo 26$ e viene venduto ad 80$ ha maggior forza contrattuale di un atom che costa 30$ e viene venduto a 38$.

capirai poi sentiremo orde di fanboy " io ho il mio NUOVO iphone con processore intel mica quello schifo di arm!"

come iniziare un flame, ma è possibile evitare queste inutili frasi?
tornando I.T.
Spero di poter provare una di queste bestiole al più presto.

Vabbé é piu' potente, e allora? Apple vanta comunque performances migliori dei coreani che a loro volta non utiizzano baytrail, dunque se la potevano risparmiare sta marchetta. Se oltre ad essere piu' potente sarà piu' conveniente magari apple lo monterà, visto che adotta già CPU e GPU intel per gli imac, i mac mini, i macbook pro e i macbook air. Intel questo se lo dimentica quando analizza i suoi bilanci?

Se oltre ad essere piu' potente sarà piu' conveniente magari apple lo monterà, visto che adotta già CPU e GPU intel per gli imac, i mac mini, i macbook pro e i macbook air. Intel questo se lo dimentica quando analizza i suoi bilanci?
Sara' a quello che puntano, visto che ne vendono letteralmente a vagonate...

Se parliamo di costi, con Atom BTrail è possibile avere tablet a 299$ al lancio, quindi direi che anche a livello di costi sono ottimi, se si considera che tablet con Snapdragon 800 hanno costi molto più elevati.
Di queste cifre non sai quanto è il prezzo vero di questi chip.
Fai conto che Qualcomm ne vende una valanga e mezza e da leader del mercato fa i prezzi più o meno che vuole.
Di Atom per ora ne hanno venduti 4 (sì proprio 4, quelli per i prototipi e basta) e quindi Intel può volerli vendere sotto costo per riuscire ad aprirsi un varco che per 4 anni non è sempre stato chiuso.
D'altronde come detto, il mercato mobile è fatto di grandi (grandissimi) numeri, non di poche ma costose CPU come nel mondo PC. Se vuoi ammortizzare costi e investimenti in sviluppo e (per chi ce le ha) fabbriche, devi venderne una montagna.
Intel non solo non riesce a venderne una scatola, ma ha fabbriche costosissime e cerca di competere con un processo produttivo più costoso (non importa quanto è raffinato il processo, una maschera a 14 nm costa uno sproposito in più di una a 28nm e bisogna ammortizzarla, o con grandi numeri o con grandi ricarichi).
Inoltre non può permettersi i ricarichi cui era (o è) abituata con le CPU per PC/Workstation/Server.

L'affare non è tanto facile nemmeno per loro anche se hanno 2 processi produttivi di vantaggio.
Le trimestrali comunque parlano da sole: Intel è in discesa, Apple e Qualcomm alle stelle. E come sempre, per Intel, si proverà con il prossimo prodotto a fare concorrenza (ogni volta per farsi belli comparano il loro ultimo gioiello con qualcosa fatto con tecnologia ormai prossima al pensionamento e ogni volta che arrivano sul mercato con il loro gioiello c'è già qualcsa di meglio che lo frega alla grande).
Magari questa volta riuscirà ad avere più visibilità se riesce ad uscire prima dell'arrivo dei 20nm da parte di TSMC e Samsung. Altrimenti, altro giro, altra corsa (e altri miliardi di dollari da investire per continuare a inseguire).

[
Le trimestrali comunque parlano da sole: Intel è in discesa, Apple e Qualcomm alle stelle.

leggendole dire che hai sbagliato aziedna Intel ha un portafoglio molto forte e se per te discesa significa guadagnare 99 quando l'hanno prima guadagnava 100 allora si tutte le aziende al mondo sono in calo. Meglio non confrontare i valori di una bolla come apple co quelli di intel che sono da decenni solidi e molto piu affidabili.
E poi hai citato 3 aziende molto diverse come caratteristiche che vendono anche prodotti molti diversi in segmenti diversi quindi inconfrontabili in questo modo.

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

@PaulGuru
L'architettura ARM è stata storicamente sempre superiore a quella x86 sul lato consumi, che in questo campo valgono molto più delle prestazioni.

Oggi Intel riesce a proporre prodotti competitivi (competitivi, non certo superiori in modo schiacciante alla concorrenza, difatti ha necessità di fare proclami su come il loro atom sia superiore agli A7, visto che non è cosa così evidente) grazie ad una superiorità nel processo produttivo.

Chiediti perchè i processori Intel in questo ambito non riescono a penetrare il mercato, tanti motivi sono stati scritti anche in questo topic.

E' irrilevante.
quello che conta in tecnologia e informatica è il risultato e il costo del prodotto, se è competitivo come questo si è raggiunto alla fine non importa a nessuno in nessun campo.

E' quel che ho sempre detto; quel che conta è il rapporto prezzo/prestazione (e direi prestazione effettivamente utilizzata, non quella di punta); ma non mi pare che Intel sia storicamente la soluzione migliore al riguardo.

Quando fa comodo si critica la concorrenza che per pareggiare i conti in prestazioni deve mettere più roba (vedi 8 core, bella forza, per andare come noi con 4..."), quando non fa comodo diventa un fattore "irrilevante" avere 10 volte più "roba"....

leggendole dire che hai sbagliato aziedna Intel ha un portafoglio molto forte e se per te discesa significa guadagnare 99 quando l'hanno prima guadagnava 100 allora si tutte le aziende al mondo sono in calo. Meglio non confrontare i valori di una bolla come apple co quelli di intel che sono da decenni solidi e molto piu affidabili.
E poi hai citato 3 aziende molto diverse come caratteristiche che vendono anche prodotti molti diversi in segmenti diversi quindi inconfrontabili in questo modo.

Intel parte da una posizione unica di dominatrice del mercato nel mondo PC. E' lì che ha sempre fatto numeri da capogiro per quanto riguarda il fatturato.
Con il fatto che ultimamente i PC (ma anche i server) sono in calo, il problema dell'uso delle fabbriche (si dice che più di metà delle fabbriche siano "disoccupate") Intel deve trovare il modo di fare cassa con altro.
Produrre SoC per il mercato mobile è una delle soluzioni, ma come già detto i problemi sono tanti: non ne vende, non è competitiva per costi che si sobbarca lei per riuscire a vendere a prezzi decenti e quindi non fa il ricarico necessario per pagare le sue fabbriche. Che ogni anno costano sempre di più (e tanto).
Il fatto che ancora oggi fatturi uno sproposito non deve trarre in inganno. Lo farà ancira per lungo tempo, la ma curva è in discesa. Si è spezzato il trend "il processo produttivo mi costa di più ma vendo anche più processori dell'anno passato per compensare".
I processi produttivi costano ora enormemente di più (vedi l'esborso extra non preventivato per i 14nm) e il numero di processori che sono fabbricati sono inferiori.

Le aziende avranno anche caratteristiche differenti ma sono in competizione nel mondo mobile, quindi sì, si può (e deve) fare un confronto.
Apple sarà una bolla, ma di sicuro per ora vende una quantità di propri chip a camionate, cosa che le permette di fare un po' quello che vuole, compreso snobbare i prodotti degli altri.
Qualcomm è l'alter ego di Intel nel campo mobile: produce e vende una quantità di CPU ogni anno che Intel non ha mai visto in tutta la sua vita, ed è un concorrente diretto di Intel nel campo mobile. Qualcomm ha anche la sua GPU e quindi, come Intel, non dipende da nessun altro e anche lei è libera di fare e sviluppare quello che vuole.

Sono proprio questi nuovi attori (che siano bolle o meno solo il tempo lo dirà) a dare i gratttacapi a Intel oggi. Non ci fossero loro Intel potrebbe ancora oggi vendere un merdosissimo Atom fatto con 1 processo produttivo più vecchio a prezzi esagerati e godersi così maggiori introiti e ricicclando le vecchie fabbriche che oggi invece non valgono più niente.
Invece ha dovuto far avanzare (e di brutto) le tecnologie per risucire a competere, ma questo le costa parecchio.
Se non sfonda in qualche maniera trovo difficile per Intel proseguire sul campo del mantenimento della competività solo con il processo produttivo, cosa che anche in questa intervista risulta palesemente dichiarata. E' sola contro il resto dell'armata ARM, che fa numeri da capogiro (oltre un miliardo di SoC l'anno), armata che finanzia le altre fabbriche che non necessitano di correre per sfornare qualcosa di competitivo.

E' un cambiamento della situazione complesso che Intel non ha mai dovuto affrontare prima. Ha il vantaggio di avere ancora parecchi introiti dal mondo PC/Server, ma sul mobile è un disastro che metà basta e non vedo alcun motivo di pensare che l'anno prossimo, o tra 2 le cose possano essere diverse. Anzi, con l'introduzione dei SoC a 64bit anche per il mondo server le cose potrebbero anche perggiorare.

@CrapaDiLegno
A tutto il tuo discorso aggiungerei anche una potenziale ripresa di AMD grazie all'affinamento della nuova architettura ma soprattutto all'affinamento dei nuovi processi produttivi da parte delle fonderie alternative ad Intel.
La quantità di denaro mosso dal mercato Mobile sta facendo muovere a sua volta gli investimenti delle fonderie sui processi produttivi, cosa di cui anche AMD potrebbe indirettamente beneficiare.
Bisogna però dire che tra ritardi e annunci disattesi i dubbi in questa ripresa cominciano ad essere molto forti, ma a mio parere sono ancora plausibili, anche se solo per una ripresa parziale.

Certo, probabilmente anche con una rinnovata competitività AMD non inciderà granché sulle quote di mercato di Intel nel mondo PC, ma può essere una piccola preoccupazione in più, che magari costringe Intel almeno in parte a rivedere la ripartizione dei propri investimenti tra PC e mondo mobile, sottraendo qualche risorsa a questi ultimi che ora hanno evidente priorità.

@PaulGuru
L'architettura ARM è stata storicamente sempre superiore a quella x86 sul lato consumi, che in questo campo valgono molto più delle prestazioni.

Oggi Intel riesce a proporre prodotti competitivi (competitivi, non certo superiori in modo schiacciante alla concorrenza, difatti ha necessità di fare proclami su come il loro atom sia superiore agli A7, visto che non è cosa così evidente) grazie ad una superiorità nel processo produttivo.

Chiediti perchè i processori Intel in questo ambito non riescono a penetrare il mercato, tanti motivi sono stati scritti anche in questo topic.Il vero problema dei prodotti montanti questo tipo di prodotti è il prezzo elevato abbinato all'ignoranza.

Essendo gli utonti a rappresentare il 90% dell'utenza che domina il mercato mobile tutto gira sull'estetica, sulle chicche e sulla moda di turno, vedi i prodotti Apple.

Intel è in vantaggio sul processo produttivo lo è sempre ed anche se non lo fosse, le prestazioni di questo bay trail sono doppie o addirittura triple rispetto agli ARM, ed è previsto un altro pesante incremento di IPC per core con la prossima generazione.
ARM è superiore durante il consumo in idle ma non in load e prima o poi la cosa è destinata a diventare trascurabile non appena le capacità delle batterie aumenterà.

@PaulGuru
L'ignoranza non c'entra nulla, chi sceglie i chip sono i produttori di telefoni, e stai sicuro che sono molto meno ignoranti di noi.

Le prestazioni di questo bay trail non sono affatto doppie rispetto ai processori ARM, a meno che tu non li stia paragonando con la generazione attuale che verrà presto sostituita (anzi, in parte lo è già stata, con gli Apple A7 di cui parla l'articolo).

Non mi pare che si sia parlato di consistente aumento di ipc con i prossimi atom, ma di miglioramento delle prestazioni grazie al nuovo processo produttivo a 14nm (e qui torniamo al discorso sui processi produttivi).

Il problema dei consumi non è affatto trascurabile, le batterie non migliorano in maniera adeguata da parecchio tempo, se Intel facesse affidamento su questo, beh, non sarebbe molto furba.
Oltretutto se migliorano le batterie migliorano per tutti, quindi se c'è un gap oggi, ci sarà anche un futuro.

Credo che i motivi di questa marchetta siano imputabili anche al fatto che lenovo li ha scaricati di recente, e quindi stanno cercando qualcun altro che monti su il loro soc.

@PaulGuru
L'ignoranza non c'entra nulla, chi sceglie i chip sono i produttori di telefoni, e stai sicuro che sono molto meno ignoranti di noi.

Le prestazioni di questo bay trail non sono affatto doppie rispetto ai processori ARM, a meno che tu non li stia paragonando con la generazione attuale che verrà presto sostituita (anzi, in parte lo è già stata, con gli Apple A7 di cui parla l'articolo).

Non mi pare che si sia parlato di consistente aumento di ipc con i prossimi atom, ma di miglioramento delle prestazioni grazie al nuovo processo produttivo a 14nm (e qui torniamo al discorso sui processi produttivi).

Il problema dei consumi non è affatto trascurabile, le batterie non migliorano in maniera adeguata da parecchio tempo, se Intel facesse affidamento su questo, beh, non sarebbe molto furba.
Oltretutto se migliorano le batterie migliorano per tutti, quindi se c'è un gap oggi, ci sarà anche un futuro.
Si ma un tablet che rimane carico 2gg anzichè uno perde molto di significato, oltre un certo limite poi il resto diventa superfluo, in quanto a casa a ricaricarlo ci dovrai passare per forza a meno che non sei nel deserto o in una giungla amazzonica.

Rispetto ad un Exinos 4412 questo Bay Trail fa il doppio o il triplo delle prestazioni, veramente impietoso : LINK (http://www.hwupgrade.it/articoli/tablet/3801/intel-atom-z3770-la-nuova-piattaforma-per-tablet-in-test_3.html)
Per il prossimo Airmont Intel ha detto che prevede di raggiungere l'IPC per clock di un Phenom II.

Il motivo per cui i produttori usano ARM è perchè costa meno e quindi possono o sfornare modelli più abbordabili oppure come Apple tirarci giù un prezzo con una % di guadagno ( ladrata ) molto superiore.

@PaulGuru
Per molti farebbe la differenza comunque, un'autonomia di due giorni significa che il dispositivo non ti lascia a piedi se fai un uso più intenso del solito, significa non dover sempre dipendere da una presa, significa poter evitare di portarsi dietro il caricabatterie e cercare una presa se stai una notte fuori casa.
Che senso avrebbe per chi produce questi dispositivi puntare su un SOC più limitato da questo punto di vista?
Ricorda che stiamo parlando di dispositivi handheld, dove la portabilità è di massima importanza.

I Bay Trail sono ottimi SOC, ma li vedo bene solo per dei tablet e convertibili economici con Windows (non RT), ma non a competere con gli ARM nel loro campo.

Certo, se lo paragoni all'Exynos è molto superiore. Ma non è con l'Exynos che Bay Trail deve confrontarsi (difatti in questa stessa news lo si confronta all'A7).
E in ogni caso non dovresti parlare di "prestazioni doppie rispetto ad ARM" come hai fatto, perchè così distorci la realtà e fai passare un'idea sbagliata.

Raggiungere l'IPC di un phenom II non è un traguardo lontano, già ora sono molto vicini, così come lo sono le nuove apu Jaguar di AMD.

Il motivo per cui ARM viene utilizzato non è uno solo, come ti dicevo, puoi rileggere quanto scritto in questo topic.
In ogni caso il costo è uno dei parametri fondamentali, se Intel per riuscire a competere deve creare un chip più complesso e costoso, allora non ha fatto un così buon lavoro (del resto il fatto che a differenza di Apple con l'A7 Intel non abbia dichiarato il numero di transistor dell'Atom può essere una spia del fatto che non sia un dato a suo favore).

ARM è sempre ARM, quel 4412 è un quad A9, l'Apple A7 è un dual A57 ( la versione a 64bit dell'A15 ) quando vuoi che cambi l'IPC per core ? 20-30% ? Senza contare che da quanto ho visto A7 è addirittura un dual quindi sto Intel se lo inghiotte tutto intero.

La portabilità va bene ma fino ad un certo punto, un Acer W700 con i5 è stimato per 7-8 ore di utilizzo, questa cpu che consuma molto meno figurati, se si riuscisse ad arrivare ad un intera giornata con questi Intel poi il resto andrebbe a farsi benedire, certo rimanere fuori casa per più di un giorno può succedere ma fuori casa non vuol dire sotto un ponte o dentro una tenda ( e se accade il tablet è l'ultimo dei problemi ), in hotel puoi ricaricarlo comunque, idem in ufficio o a casa altrui.

Una durata superiore alla giornata servirebbe a chi ? Chi fa lunghe escursioni in zone deserte, pochissime persone e soprattutto mediamente in un anno quante volte si può fare ?

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

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

http://www.anandtech.com/show/7335/the-iphone-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.

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

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.

e allora fallo te un bench se non ti và nemmeno bene anan…..:mc:
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.

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

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.

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.

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 cu:ciapet:o 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 ? :read:

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

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

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.

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.

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.

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

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

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

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.

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 (http://www-cs-faculty.stanford.edu/~eroberts/courses/soco/projects/2000-01/risc/risccisc/) 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.

Fintando che si usa software non troppo complesso l'architettura arm ha una maggiore effecenza (e non ci piove).
:sofico:
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.

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.

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

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.

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

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.

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

:sofico:
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à. :mbe:

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.

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


Quindi se l'architettura A è il 50% più efficente dell'architettura B nella riduzione a numeri primi con numeri sotto il valone di 1000000, lo sarà anche per numeri sopra 10^23?

riguardo ai test cerca arm phoronix oppure open benchmark e spiegami perchè nonostante linux giri su arm non si hanno notebook o netbook con arm (che garantirebbero un parco software vastissimo unito ad una autonomia imbarazzante per x86 ad un prezzo molto più basso) in giro.
Arm non è l'architettura destinata a fare da motore ad un sistema che sostituisce l'ambiente desktop per 1000 motivi, anche se sembrerebbe possibile fare macchine efficentissime.
La risposta l'hai data tu:


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

La parte che non capisco di quello che hai scritto è come un eseguibile più voluminoso (quello dell'architettura Arm) possa occupare meno ram di un eseguibile meno voluminoso (CISC).
Il fatto poi che in hardware siano state utilizzate implementazioni che possono sostituire 4 operazioni con due (neon), ma solo in ambiti specifici dice tutto e niente.
Purtroppo le cpu arm hanno come base il concetto di dividere operazioni complesse in più operazioni semplici (per guadagnare in efficenza) da poter eseguire in singola passata (invece che in una serie di cicli) e questo mostra il fianco però a codice che in caso di occupazione massiccia dei registri fanno decadere le prestazioni complessive di vari ordini di grandezza.
Il parcheggiare o "congelare" i th non utilizzati serve proprio a non far decadere le prestazioni lato cpu e non come presumibile in prima analisi a liberare ram, e quello che tu dici dipenda dall'os invece è una scelta logica a causi di limitazioni dell'architettura.
Quando Arm deciderà di aggredire il mercato delle cpu ad alte prestazioni si ritroverà a dover decidere se continuare ad avere un chip economico da produrre (i consumi sono relativi) oppure chip dal costo esorbitante (ad oggi uno snapdragon 800 costa sopra i 22$ (addirittura si parla di soc completo dal costo di 79$).
Beninteso non parteggio ne per Arm ne per X86, ma credo che arm sarà il soc per dispositivi ultraportatili per i prossimi 5 anni, mentre x86 si prenderà il mercato dei tablet a medio ed alto costo (dai 350€ in su).
Tra cinque anni probabilmente le cpu x86 saranno dedicati a mercati di nicchia (come lo erano le arm fino a 5 anni fa) ed il grosso delle vendite sarà fatto da chip arm anche per i dispositivi a media efficenza (attuale settore desktop e notebook), sempre che nel frattempo non ci sarà un evoluzione dell'utilizzo tale da richiedere in determinati software elevatissime potenze di calcolo (e gli unici campi che mi vengono in mente sono sicurezza dei dati e crittografia delle trasmissioni ed IA)

Quindi se l'architettura A è il 50% più efficente dell'architettura B nella riduzione a numeri primi con numeri sotto il valone di 1000000, lo sarà anche per numeri sopra 10^23?

Si tratta di tre cose distinte:
1) architettura "ad alto livello";
2) la sua implementazioni in hardware;
3) il software che viene eseguito su di essa.

Il caso che descrivi è quello che si ha quando due specifiche implementazioni delle architetture A e B hanno cache di dimensione differente ed in cui il working set di una implementazione di un certo algoritmo tende a crescere con il numero di valori processati.

In poche parole: stai descrivendo una situazioni in cui è la dimensione delle cache a fare la differenza, non il set d'istruzioni utilizzato.

Infatti esiste pure una metodologia di ottimizzazione del codice (la block optimization) basata sulla dimensione delle cache a prescindere dal set d'istruzioni del processore.

riguardo ai test cerca arm phoronix oppure open benchmark e spiegami perchè nonostante linux giri su arm non si hanno notebook o netbook con arm (che garantirebbero un parco software vastissimo unito ad una autonomia imbarazzante per x86 ad un prezzo molto più basso) in giro.

Eppure lo avevo spiegato per bene: dipende tutto dal software che la gran massa degli utenti si aspetta di poter utilizzare quando acquista un notebook o un netbook (che gira quasi tutto solo sotto Windows per x86) e dal fatto che le cpu per notebook e desktop si possono permettere consumi molto più elevati ed attualmente nessuno produce ARM che privilegiano le prestazioni a costo di consumi simili.

Arm non è l'architettura destinata a fare da motore ad un sistema che sostituisce l'ambiente desktop per 1000 motivi, anche se sembrerebbe possibile fare macchine efficentissime.

Come avevo scritto pure io, con la differenza che ho aggiunto "per ora". ;)


La parte che non capisco di quello che hai scritto è come un eseguibile più voluminoso (quello dell'architettura Arm) possa occupare meno ram di un eseguibile meno voluminoso (CISC).

Perchè la classificazione RISC vs. CISC è molto generica, quello che conta sono le specifiche architetture e set d'istruzioni.

CISC (Complex Instruction Set Computer)
indica architetture con set d'istruzioni "complessi" nel senso di aventi una codifica "complicata" (ma non sempre), spesso con parecchi registri dedicati
a particolari funzioni e con istruzioni cosi complesse che non potevano essere eseguite direttamente da un ALU ma spezzate in una sequenza id istruzioni codificate in microcodice.
La media lunghezza delle istruzioni può essere più o meno grande, ma non è fondamentale per classificare un architettura come CISC.
In generale comunque, vista la notevole "asimmetria" (molti casi particolari) della codifica, le istruzioni sono più "compatte" (ma non sempre) se si sfruttano le particolarità dle set d'istruzioni.

RISC (Reduced Instruction Set Computer)
indica architetture che mirano ad eseguire con la massima efficienza in hardware le istruzioni ritenute "più importanti" per un motivo o per l'altro, in modo da ottenere implementazioni "semplici" che possono salire meglio in frequenza, utilizzare pochi transistor, ecc.
Questo derivava dalla scoperta (analizzando i codice prodotto dai compilatori) che molte delle istruzioni "complicate" dei CISC venivano usate poco (quindi eliminarle incideva poco sulle prestazioni e le semplificazioni che derivavano permettevano di salire di frequenza, ecc. ed avere alla fine prestazioni superiori).
In generale questo comportava usare istruzioni di lunghezza omogenea
(di solito uguale all'ampiezza del bus dati "di riferimento" della prima implementazione) perchè semplificava enormemente il decoder istruzioni
con al massimo pochi casi particolari.
Questo spesso si traduceva in istruzioni ampie 32bit, ma ad esempio i Renesas SH hanno istruzioni nella maggior parte ampie 16bit.

Ma ovviamente anche le architetture nate come "RISC puri" hanno subito un evoluzione e neppure all'inizio erano "tutte uguali" visto che sebbene si avesse un idea dei "difetti" dei CISC tra i progettisti c'erano idee differenti su cosa potesse essere essenziale oppure no e su cosa valesse la pena implementare per avere prestazioni più elevate.

Abbiamo quindi le cpu POWER ed Alpha (quelle inizialmente più vicine a dei RISC "puri"), le MIPS (con la particolarità dell' "istruzione seguibile dopo il jump") le SPARC (con il set di registri "a finestre"), ecc.

ARM "nasce" nel periodo del boom di ideazioni di cpu RISC e viene spesso classificato come tale, ma ...
In realtà fu progettato più come "erede del 6502", non c'erano veri "fondamentalisti dell'architettura RISC" tra i suoi ideatori, ma semmai gente dalle idee molto aperte che voleva una cpu efficiente.
Per questo ad esempio il suo set d'istruzioni "base" ha la maggior parte delle istruzioni ad esecuzione condizionale e prevede sin da subito le estensioni per coprocessori (sia esterni che integrati nel core) che decisamente non sono presenti negli altri RISC (se non tramite estensioni successive al loro set d'istruzioni "base" ed in forma più limitata).
Fu anche per questo che fu poi possibile "dimezzare la lunghezza media delle istruzioni" con le estensioni THUMB e THUMB2 mantenendo piena retrocompatibilità ed ottenendo codice circa il 30% più "compatto" con una semplice ricompilazione (e pure più veloce su implementazioni con bus dati a 16bit, cosa molto frequente su certe implementazioni per applicazioni embedded).

A parte quanto esposto sopra, il "vantaggio di compattezza" che pensi che abbiano gli x86 non è così rilevante (al punto che pure per roba compilata nativamente per Android quasi nessuno usa le THUMB2 visto che il grosso del consumo di memoria non dipende dalla dimensioni del codice, ma da bitmap ed altri dati).

Il fatto poi che in hardware siano state utilizzate implementazioni che possono sostituire 4 operazioni con due (neon), ma solo in ambiti specifici dice tutto e niente.
Purtroppo le cpu arm hanno come base il concetto di dividere operazioni complesse in più operazioni semplici (per guadagnare in efficenza) da poter eseguire in singola passata (invece che in una serie di cicli) e questo mostra il fianco però a codice che in caso di occupazione massiccia dei registri fanno decadere le prestazioni complessive di vari ordini di grandezza.

Attualmente non è che questo costituisca un problema significativo, se necessario gli ARM possono ricevere ulteriori estensioni al set d'istruzioni, ma attualmente non è che siano in una situazione così "svantaggiosa".

Anche Intel prima ha aggiunto le MMX (con 8 registri a 64bit), poi le SSE (con 8 registri a 128bit e 16 registri a 128bit in modalità a x86-64), poi le AVX (con 16 registri a 256bit) ed infine le AVX-512 (con 32 registri a 512bit).

Tutto il resto dipende poi da scelte a livello di implementazione fisica, non di set d'istruzioni o di "scelte progettuali ad alto livello".

Ad esempio, se ricordo bene gli Atom precedenti a Bay Trail potevano arrivare a max 1.5 operazioni DP per ciclo (1 addizione SSE per ciclo ed 1 moltiplicazione SSE ogni due cicli) e 6 operazioni SP per ciclo (4 addizioni SSE per ciclo e 4 moltiplicazione SSE ogni due cicli); mentre invece un core Krait o un core Cortex A15 fanno 2 operazioni DP per ciclo (FMA oppure multiply-add) oppure 8 operazioni SP per ciclo (4 FMA oppure 4 multiply-add).


Il parcheggiare o "congelare" i th non utilizzati serve proprio a non far decadere le prestazioni lato cpu e non come presumibile in prima analisi a liberare ram, e quello che tu dici dipenda dall'os invece è una scelta logica a causi di limitazioni dell'architettura.

Scusa, ma le "prestazioni lato cpu" al massimo dipendono dal numero minimo di thread in esecuzione (nel caso di cpu tipo i "vecchi" Atom con multithreading ed esecuzione in-order), indipendentemente dal numero massimo di thread o dalla quantità di memoria, questo perchè in un S.O. appena decente si usano strategie di scheduling e gestione delle priorità che prescindono dalla cpu o dal set d'istruzioni utilizzato (ma che sono influenzate dalla ram disponibile e da quello che fanno i thread in termini di utilizzo delle risorse disponibili).

Infatti se se fai girare del software scritto con il cu:ciapet:o su Android per ARM o su Android per x86, a parità di quantità di ram e di thread eseguibili simultaneamente dai core noterai quasi gli stessi problemi anche se magari l'x86 fosse come minimo veloce il doppio.

Infatti, spesso su Android le applicazioni con le parti critiche scritte in C/C++ e compilate con l'NDK hanno molti meno problemi riguardo ram e massimo numero di thread perchè mediamente vengono scritte facendo molta più attenzione a come si alloca la memoria ecc. ecc.
(in media chi programma in Java o C# tende a sottovalutare il fatto che anche se c'è il garbage collector, del codice scritto con i piedi che alloca male la memoria magari non produce crash "diretti" ma si mangia un sacco di memoria e fa scattare troppo spesso la garbage collection).
E tutto questo a prescindere dalla cpu.

Si tratta di tre cose distinte:
1) architettura "ad alto livello";
2) la sua implementazioni in hardware;
3) il software che viene eseguito su di essa.

Il caso che descrivi è quello che si ha quando due specifiche implementazioni delle architetture A e B hanno cache di dimensione differente ed in cui il working set di una implementazione di un certo algoritmo tende a crescere con il numero di valori processati.

In poche parole: stai descrivendo una situazioni in cui è la dimensione delle cache a fare la differenza, non il set d'istruzioni utilizzato.

Infatti esiste pure una metodologia di ottimizzazione del codice (la block optimization) basata sulla dimensione delle cache a prescindere dal set d'istruzioni del processore.



Eppure lo avevo spiegato per bene: dipende tutto dal software che la gran massa degli utenti si aspetta di poter utilizzare quando acquista un notebook o un netbook (che gira quasi tutto solo sotto Windows per x86) e dal fatto che le cpu per notebook e desktop si possono permettere consumi molto più elevati ed attualmente nessuno produce ARM che privilegiano le prestazioni a costo di consumi simili.



Come avevo scritto pure io, con la differenza che ho aggiunto "per ora". ;)



Perchè la classificazione RISC vs. CISC è molto generica, quello che conta sono le specifiche architetture e set d'istruzioni.

CISC (Complex Instruction Set Computer)
indica architetture con set d'istruzioni "complessi" nel senso di aventi una codifica "complicata" (ma non sempre), spesso con parecchi registri dedicati
a particolari funzioni e con istruzioni cosi complesse che non potevano essere eseguite direttamente da un ALU ma spezzate in una sequenza id istruzioni codificate in microcodice.
La media lunghezza delle istruzioni può essere più o meno grande, ma non è fondamentale per classificare un architettura come CISC.
In generale comunque, vista la notevole "asimmetria" (molti casi particolari) della codifica, le istruzioni sono più "compatte" (ma non sempre) se si sfruttano le particolarità dle set d'istruzioni.

RISC (Reduced Instruction Set Computer)
indica architetture che mirano ad eseguire con la massima efficienza in hardware le istruzioni ritenute "più importanti" per un motivo o per l'altro, in modo da ottenere implementazioni "semplici" che possono salire meglio in frequenza, utilizzare pochi transistor, ecc.
Questo derivava dalla scoperta (analizzando i codice prodotto dai compilatori) che molte delle istruzioni "complicate" dei CISC venivano usate poco (quindi eliminarle incideva poco sulle prestazioni e le semplificazioni che derivavano permettevano di salire di frequenza, ecc. ed avere alla fine prestazioni superiori).
In generale questo comportava usare istruzioni di lunghezza omogenea
(di solito uguale all'ampiezza del bus dati "di riferimento" della prima implementazione) perchè semplificava enormemente il decoder istruzioni
con al massimo pochi casi particolari.
Questo spesso si traduceva in istruzioni ampie 32bit, ma ad esempio i Renesas SH hanno istruzioni nella maggior parte ampie 16bit.

Ma ovviamente anche le architetture nate come "RISC puri" hanno subito un evoluzione e neppure all'inizio erano "tutte uguali" visto che sebbene si avesse un idea dei "difetti" dei CISC tra i progettisti c'erano idee differenti su cosa potesse essere essenziale oppure no e su cosa valesse la pena implementare per avere prestazioni più elevate.

Abbiamo quindi le cpu POWER ed Alpha (quelle inizialmente più vicine a dei RISC "puri"), le MIPS (con la particolarità dell' "istruzione seguibile dopo il jump") le SPARC (con il set di registri "a finestre"), ecc.

ARM "nasce" nel periodo del boom di ideazioni di cpu RISC e viene spesso classificato come tale, ma ...
In realtà fu progettato più come "erede del 6502", non c'erano veri "fondamentalisti dell'architettura RISC" tra i suoi ideatori, ma semmai gente dalle idee molto aperte che voleva una cpu efficiente.
Per questo ad esempio il suo set d'istruzioni "base" ha la maggior parte delle istruzioni ad esecuzione condizionale e prevede sin da subito le estensioni per coprocessori (sia esterni che integrati nel core) che decisamente non sono presenti negli altri RISC (se non tramite estensioni successive al loro set d'istruzioni "base" ed in forma più limitata).
Fu anche per questo che fu poi possibile "dimezzare la lunghezza media delle istruzioni" con le estensioni THUMB e THUMB2 mantenendo piena retrocompatibilità ed ottenendo codice circa il 30% più "compatto" con una semplice ricompilazione (e pure più veloce su implementazioni con bus dati a 16bit, cosa molto frequente su certe implementazioni per applicazioni embedded).

A parte quanto esposto sopra, il "vantaggio di compattezza" che pensi che abbiano gli x86 non è così rilevante (al punto che pure per roba compilata nativamente per Android quasi nessuno usa le THUMB2 visto che il grosso del consumo di memoria non dipende dalla dimensioni del codice, ma da bitmap ed altri dati).



Attualmente non è che questo costituisca un problema significativo, se necessario gli ARM possono ricevere ulteriori estensioni al set d'istruzioni, ma attualmente non è che siano in una situazione così "svantaggiosa".

Anche Intel prima ha aggiunto le MMX (con 8 registri a 64bit), poi le SSE (con 8 registri a 128bit e 16 registri a 128bit in modalità a x86-64), poi le AVX (con 16 registri a 256bit) ed infine le AVX-512 (con 32 registri a 512bit).

Tutto il resto dipende poi da scelte a livello di implementazione fisica, non di set d'istruzioni o di "scelte progettuali ad alto livello".

Ad esempio, se ricordo bene gli Atom precedenti a Bay Trail potevano arrivare a max 1.5 operazioni DP per ciclo (1 addizione SSE per ciclo ed 1 moltiplicazione SSE ogni due cicli) e 6 operazioni SP per ciclo (4 addizioni SSE per ciclo e 4 moltiplicazione SSE ogni due cicli); mentre invece un core Krait o un core Cortex A15 fanno 2 operazioni DP per ciclo (FMA oppure multiply-add) oppure 8 operazioni SP per ciclo (4 FMA oppure 4 multiply-add).




Scusa, ma le "prestazioni lato cpu" al massimo dipendono dal numero minimo di thread in esecuzione (nel caso di cpu tipo i "vecchi" Atom con multithreading ed esecuzione in-order), indipendentemente dal numero massimo di thread o dalla quantità di memoria, questo perchè in un S.O. appena decente si usano strategie di scheduling e gestione delle priorità che prescindono dalla cpu o dal set d'istruzioni utilizzato (ma che sono influenzate dalla ram disponibile e da quello che fanno i thread in termini di utilizzo delle risorse disponibili).

Infatti se se fai girare del software scritto con il cu:ciapet:o su Android per ARM o su Android per x86, a parità di quantità di ram e di thread eseguibili simultaneamente dai core noterai quasi gli stessi problemi anche se magari l'x86 fosse come minimo veloce il doppio.

Infatti, spesso su Android le applicazioni con le parti critiche scritte in C/C++ e compilate con l'NDK hanno molti meno problemi riguardo ram e massimo numero di thread perchè mediamente vengono scritte facendo molta più attenzione a come si alloca la memoria ecc. ecc.
(in media chi programma in Java o C# tende a sottovalutare il fatto che anche se c'è il garbage collector, del codice scritto con i piedi che alloca male la memoria magari non produce crash "diretti" ma si mangia un sacco di memoria e fa scattare troppo spesso la garbage collection).
E tutto questo a prescindere dalla cpu.
Sto continuando a discutere con te perchè so per certo che hai conoscenze almeno 100 volte superiori alle mie in materia (a voler star stretti).
Tutto quello che hai scritto l'ho ben inteso, ma ti chiedo ugualmente alcuni chiarimenti:
Nell'esempio dell'algoritmo di sui numeri primi questo impatta solo sulla cache e non sull'esaurimento dei registri disponibili?
Aumentare cache, numero registri, bus verso la ram non impongono come conseguenza un maggior esborso energetico e complessità hardware?
Cioè non si farebbe il gioco di aumentare l'ipc (per quanto come valore potrebbe dire tutto o niente) di una percentuale inferiore al efficenza persa?
Riguardo la programmazione con il c..o hai perfettamente ragione, ma credo, e probabilmente converrai con me, che è proprio questo che rende x86 ancora meno efficente.
In ultima cosa: per certo le cpu x86 ad oggi possono spegnere (previo una piccola parte di transistor dedicati allo scopo) praticamente ogni singola parte di una cpu (da blocchi di cache ad un'intero core) ed a variare dinamicamente i rapporti di frequenza tra le varia parti (abbassare il clock del memory controller, delle cache l2-l3, addirittura ci sono tentativi di rendere asincroni le alu sui singoli core), questo è possibile in arm (credo di no)?

Non vorrei far polemica ma l'articolo dice che Bay Trail è più potente e "più efficiente" di A7.


@Gilles : la disabilitazione dei cores mi sembra che già lo facciano con ARM, Tegra dal 3 in poi ha 5 cores fisici, 1 per l'utilizzo in idle e 4 per l'utilizzo in load, l'ultimo Exynos ne ha 8 di cui 4 basati su A7 e gli altri 4 su A15, forse ciè che non possono ridurre dinamicamente sono freq e vcore.

Nell'esempio dell'algoritmo di sui numeri primi questo impatta solo sulla cache e non sull'esaurimento dei registri disponibili?

Per escludere che un numero sia primo basta che sia divisibile per uno dei primi maggiori di 1 già generati, quindi si continua a scorrere la lista/array dei numeri primi già generati e man mano che questa cresce, prima il quantitativo medio di elementi con cui si fa il test di divisione supera la dimensione della L1, poi della L2 ecc. fino al punto che prevalgono gli accessi in ram rispetto a quelli nelle cache.
Anche avere parecchi registri aiuta perchè gli interi su cui si fa la ricerca dei primi non vengono memorizzati su singoli registri ma in "multipla precisione" (liste di word di memoria, pensa a come un numero intero viene descritto come una lsita di singole cifre decimali e fai la stessa cosa usando invece word di memoria ampie qaunto i registri della cpu come "cifre") quindi più registri si hanno e più a lungo si riesce a "tenere tutto su registri" il numero a multipla precisione che si sta testando, ma di solito è la dimensone della cache (e la sua velocità rispetto agli accessi in ram) a dominare.

Aumentare cache, numero registri, bus verso la ram non impongono come conseguenza un maggior esborso energetico e complessità hardware?
Cioè non si farebbe il gioco di aumentare l'ipc (per quanto come valore potrebbe dire tutto o niente) di una percentuale inferiore al efficenza persa?

Quando si può agire su più parametri, si cerca sempre di giungere al massimo del rapporto benefici/costi cercando la combinazione ottimale, ma non esiste una regola "fissa" perchè certe limitazioni dipendono dalla tecnologia disponibile, infatti quando si lavora alla generazione successiva di un processore si eseguono anche simulazioni delle varie alternative progettuali per valutare meglio cosa comportano certe scelte.
Non a caso l'idea dei RISC è nata dall'analisi del codice generato dai compilatori delle cpu CISC e della simulazione della sua esecuzione.
Agli inizi era tutto relativamente più facile (leakage trascurabile, facile salire di frequenza, ecc.) ma poi oltre un certo punto il leakage non fu più trascurabile, i consumi diventavarono eccessivi, ecc.

In ultima cosa: per certo le cpu x86 ad oggi possono spegnere (previo una piccola parte di transistor dedicati allo scopo) praticamente ogni singola parte di una cpu (da blocchi di cache ad un'intero core) ed a variare dinamicamente i rapporti di frequenza tra le varia parti (abbassare il clock del memory controller, delle cache l2-l3, addirittura ci sono tentativi di rendere asincroni le alu sui singoli core), questo è possibile in arm (credo di no)?

Si, sono cose che vengono applicate anche agli ARM, infatti se ricordo bene la prima cpu completemente asincrona è stato un ARM (progetto Amulet).

Non vorrei far polemica ma l'articolo dice che Bay Trail è più potente e "più efficiente" di A7.


@Gilles : la disabilitazione dei cores mi sembra che già lo facciano con ARM, Tegra dal 3 in poi ha 5 cores fisici, 1 per l'utilizzo in idle e 4 per l'utilizzo in load, l'ultimo Exynos ne ha 8 di cui 4 basati su A7 e gli altri 4 su A15, forse ciè che non possono ridurre dinamicamente sono freq e vcore.
Atom è più potente ed efficente solo per il processo produttivo (normalizzando le tensioni applicate ti ritroveresti atom a consumare il 25% in più rispetto A7)
Poi io ho fatto quella domanda sapendo che nessuna cpu Arm in produzione ha l'asicronia interna, ed il companion o l'exynos quad sono due cpu che swichano e prediligono stadi di basso consumo con cpu low performance alternandoli a picchi di consumo passando all'high performance, oltremodo consumando transistor a causa della doppia cpu (e questa io la chiamo inefficenza allo stato puro, sopratutto nel caso di samsung).

Per escludere che un numero sia primo basta che sia divisibile per uno dei primi maggiori di 1 già generati, quindi si continua a scorrere la lista/array dei numeri primi già generati e man mano che questa cresce, prima il quantitativo medio di elementi con cui si fa il test di divisione supera la dimensione della L1, poi della L2 ecc. fino al punto che prevalgono gli accessi in ram rispetto a quelli nelle cache.
Anche avere parecchi registri aiuta perchè gli interi su cui si fa la ricerca dei primi non vengono memorizzati su singoli registri ma in "multipla precisione" (liste di word di memoria, pensa a come un numero intero viene descritto come una lsita di singole cifre decimali e fai la stessa cosa usando invece word di memoria ampie qaunto i registri della cpu come "cifre") quindi più registri si hanno e più a lungo si riesce a "tenere tutto su registri" il numero a multipla precisione che si sta testando, ma di solito è la dimensone della cache (e la sua velocità rispetto agli accessi in ram) a dominare.



Quando si può agire su più parametri, si cerca sempre di giungere al massimo del rapporto benefici/costi cercando la combinazione ottimale, ma non esiste una regola "fissa" perchè certe limitazioni dipendono dalla tecnologia disponibile, infatti quando si lavora alla generazione successiva di un processore si eseguono anche simulazioni delle varie alternative progettuali per valutare meglio cosa comportano certe scelte.
Non a caso l'idea dei RISC è nata dall'analisi del codice generato dai compilatori delle cpu CISC e della simulazione della sua esecuzione.
Agli inizi era tutto relativamente più facile (leakage trascurabile, facile salire di frequenza, ecc.) ma poi oltre un certo punto il leakage non fu più trascurabile, i consumi diventavarono eccessivi, ecc.



Si, sono cose che vengono applicate anche agli ARM, infatti se ricordo bene la prima cpu completemente asincrona è stato un ARM (progetto Amulet).
Quindi arm vs x86 cambia efficenza con l'esaurimento dei registri (mentre x86 deve in ogni caso ricrivere i registri).
Ps Amulet è l'unica cpu arm in grado di lavorare in modalità asincrona, ma pagando in termini di ipc il 28% circa rispetto ad un corrispettivo arm classico (quindi quasi la stessa efficenza di x86).
Strada abbandonata perchè non porta a nessun vantaggio concreto.
Non so se però i core arm lavorano a frequenza fissa per moltiplicatore interno, o variabile senza moltiplicatore.
Questa caratteristica potrebbe o meno permettere una gestione asincrona delle altre parti della cpu agevolmente e senza una perdita eccessiva di efficenza (relativamente ai costi di implementazione)

Scusate ma che discorsi sono che Atom è superiore per il PP ?

Cos'è adesso il PP non conta o sarebbe una scusante ? Se A7 è indietro non è di certo colpa di Intel, allora diciamo pure che anche AMD è indietro per colpa del PP ma che discorsi sono ?

Atom è più potente ed efficente solo per il processo produttivo (normalizzando le tensioni applicate ti ritroveresti atom a consumare il 25% in più rispetto A7)
Poi io ho fatto quella domanda sapendo che nessuna cpu Arm in produzione ha l'asicronia interna, ed il companion o l'exynos quad sono due cpu che swichano e prediligono stadi di basso consumo con cpu low performance alternandoli a picchi di consumo passando all'high performance, oltremodo consumando transistor a causa della doppia cpu (e questa io la chiamo inefficenza allo stato puro, sopratutto nel caso di samsung).

La scelta di usare certi accorgimenti oppure no non è così "semplice" come potrebbe sembrare, ad esempio se si usa la domino logic (che premette di avere prestazioni più elevate) si hanno maggiori problemi di controllo delle fluttuazioni dei consumi (e questo richiede molte più pompe di carica, più circuiteria di clock gating, ecc. sul chip).

L'approccio big.LITTLE è un altro esempio di questi tradeoff: implementato bene porta davvero a consumi più bassi e non ci sono gli "sprechi" che ti immagini visto una cpu "semplice" è molto più piccola e consuma certamente molto meno di una "potente" ma imbottita di circuiteria di risparmio energetico, come pure una cpu "potente" con meno circuiteria di risparmio energetico ... a pieno carico consuma meno e può salire di più di clock.

Quello che ha "fregato" l'approccio big.LITTLE e' che in troppi si son fatti paranoie assurde riguardo ai core "inutilizzati" ed allo "spreco" che comportano ... che non è così tanto, visto che un singolo core A7 occupa circa 1/3 dell'area di un singolo core A15 ed in modalità a basso consumo risparmia molto di più di un A15 barbatruccato con tutto quello che ci si può immaginare in termini di riduzioni dei consumi.

Quindi arm vs x86 cambia efficenza con l'esaurimento dei registri (mentre x86 deve in ogni caso ricrivere i registri).

Nel caso della ricerca dei numeri primi non è tanto rilevante (li la cache ci mette poco a diventare dominanto sulle prestazioni).
Avere registri in più in linea generale (e con parecchi casi particolari) aiuta nel caso di inner loop eseguiti molto a lungo o con codice "sequenziale" con sufficiente riutilizzo dei dati letti dalla memoria.

Ps Amulet è l'unica cpu arm in grado di lavorare in modalità asincrona, ma pagando in termini di ipc il 28% circa rispetto ad un corrispettivo arm classico (quindi quasi la stessa efficenza di x86).
Strada abbandonata perchè non porta a nessun vantaggio concreto.
Non so se però i core arm lavorano a frequenza fissa per moltiplicatore interno, o variabile senza moltiplicatore.
Questa caratteristica potrebbe o meno permettere una gestione asincrona delle altre parti della cpu agevolmente e senza una perdita eccessiva di efficenza (relativamente ai costi di implementazione)

Attualmente per le cose in cui in passato si sarebbe usata logica asincrona, sulle cpu attuali si tende ad usare la domino logic, e si, dove serve viene utilizzata anche sugli ARM.

Scusate ma che discorsi sono che Atom è superiore per il PP ?

Cos'è adesso il PP non conta o sarebbe una scusante ? Se A7 è indietro non è di certo colpa di Intel, allora diciamo pure che anche AMD è indietro per colpa del PP ma che discorsi sono ?
Se si vuole valutare l'architettura in se, il processo produttivo va escluso dall'equazione, per quanto possibile.
Se si vuole valutare il prodotto completo, allora ovviamente si valuta anche il processo produttivo.

Il problema è che ora Intel ha un grande vantaggio sul processo produttivo, ma per come si stanno evolvendo le cose questo potrebbe essere un picco, destinato a ridursi (le altre fonderie hanno in roadmap i 14nm per il 2015, non molto dopo Intel, e con un nuovo processo più adatto alla miniaturizzazione).
Senza questo vantaggio Atom perde molta della sua appetibilità, chi deve scegliere se basarsi su questi prodotti o meno valuta anche se chi li fornisce possa continuare a farlo anche in futuro con la stessa competitività.

Se si vuole valutare l'architettura in se, il processo produttivo va escluso dall'equazione, per quanto possibile.
Se si vuole valutare il prodotto completo, allora ovviamente si valuta anche il processo produttivo.

Il problema è che ora Intel ha un grande vantaggio sul processo produttivo, ma per come si stanno evolvendo le cose questo potrebbe essere un picco, destinato a ridursi (le altre fonderie hanno in roadmap i 14nm per il 2015, non molto dopo Intel, e con un nuovo processo più adatto alla miniaturizzazione).
Senza questo vantaggio Atom perde molta della sua appetibilità, chi deve scegliere se basarsi su questi prodotti o meno valuta anche se chi li fornisce possa continuare a farlo anche in futuro con la stessa competitività.
Ovviamente il consumatore guarda il prodotto completo, non vedo cosa possa servirgli guardare l'architettura dal punto di vista del futuro, se un architettura prevarrà in seguito la prossima volta si comprerà un prodotto attinente.

Il vantaggio del PP potrebbe potrebbe anche calare così come anche no e anche nel caso calasse potrebbe essere l'architettura o le features di Atom a migliorare.

Ovviamente il consumatore guarda il prodotto completo, non vedo cosa possa servirgli guardare l'architettura dal punto di vista del futuro, se un architettura prevarrà in seguito la prossima volta si comprerà un prodotto attinente.
Non è il consumatore che adotta un certo SOC per il talblet, ma il produttore.
Il consumatore al più sceglie il prodotto finito, e probabilmente di cosa ci sia dentro gli importa davvero poco.
Passare da un'architettura ad un'altra ha dei costi per chi crea i dispositivi, quindi questo cambio non si può fare tanto a cuor leggero.
Per non parlare poi di tutti gli svantaggi che ci sarebbero ad adottare i SOC Intel e di cui abbiamo già parlato.

Il vantaggio del PP potrebbe potrebbe anche calare così come anche no e anche nel caso calasse potrebbe essere l'architettura o le features di Atom a migliorare.
Per come stanno le cose ora, a meno che non salti fuori qualcosa di nuovo, direi che è più probabile un riavvicinamento.
Architettura e features possono migliorare anche per gli altri, quindi direi che per ora non ha senso includerli nell'equazione.

Il produttore può fare ovviamente ciò che ritiene più giusto ed un consumatore a cui non frega cosa cè dentro a ciò che compra è un utonto ( e questa non è nè un flame nè un offesa, è così visto che è sinonimo di ignoranza o sbaglio ? ), un utente competente e appassionato compra a pari prezzo il prodotto più potente e al momento Bay Trail è la cpu più potente di quella fascia di mercato e dotata di Windows e quindi compatibile con tutte le applicazioni da desktop.

Se fosse stato un paragone con un Kindle Fire sarebbe stata una cosa differente ma con un Apple che è da sempre nota per i furti ed i prezzi assolutamente ingiustificati non penso sia a sfavore dei prodotti montanti intel.

un utente competente e appassionato compra a pari prezzo il prodotto più potente e al momento Bay Trail è la cpu più potente di quella fascia di mercato e dotata di Windows e quindi compatibile con tutte le applicazioni da desktop.
No, un utente competente compra quello che è più adatto alle proprie esigenze (o a quelle di chi deve usare il dispositivo), e molto spesso non si tratta del prodotto più potente.
Spesso chi si fa attirare della macchina più potente a quel prezzo è l'utente poco accorto e attratto dai numeroni, che non ha ancora realizzato che la potenza è solo una delle caratteristiche e che spesso per averla si rinuncia a cose più utili.
Allo stesso modo, tra gli "utonti", è più accorto quello che valuta il dispositivo perchè funziona bene e fa quel che gli serve, e non basandosi sul valore dei benchmark, sul numero di core, ecc...

In ogni caso questo è abbastanza OT.
Intel sta cercando di entrare in un mercato dove non è in vantaggio, e dove non ha la stessa "leva" che ha in altri mercati.
Qui i produttori ci pensano bene prima di legarsi ad Intel, e giustamente. Intel deve imparare a lavorare con prodotti basati sull'esigenza del cliente e non solo sulle proprie, e modificare il modo di rapportarsi con essi.
Potrà anche affermare che Atom è più veloce ed efficiente, ma questo non basta.

Potrà anche affermare che Atom è più veloce ed efficiente, ma questo non basta.
E allora è un mercato già definito dove gli outsiders sono quelli famosi, Apple iPad e Samsung Galaxy.
Se uno fa un prodotto più potente e più efficiente e mi dici che non basta ..... non basterà mai probabilmente.

No, un utente competente compra quello che è più adatto alle proprie esigenze (o a quelle di chi deve usare il dispositivo), e molto spesso non si tratta del prodotto più potente.
Spesso chi si fa attirare della macchina più potente a quel prezzo è l'utente poco accorto e attratto dai numeroni, che non ha ancora realizzato che la potenza è solo una delle caratteristiche e che spesso per averla si rinuncia a cose più utili.
.Tipo ?
Abbiamo detto che Atom è più potente ma anche più efficiente, quale utilizzo o features rimane che potrebbe mancare ad un prodotto definitivo rispetto ad un altro, stiamo parlando di Tablet, roba abbastanza elementare, un display ad alta risoluzione, bluetooth e fotocamera più o meno in quella fascia ce l'han tutti.

E allora è un mercato già definito dove gli outsiders sono quelli famosi, Apple iPad e Samsung Galaxy.
Se uno fa un prodotto più potente e più efficiente e mi dici che non basta ..... non basterà mai probabilmente.
No, è un mercato in cui la potenza non è il solo elemento sulla cui base si sceglie l'hardware più adatto. Costi, packaging, TDP, personalizzazione, collaborazione, rapporti di forza, ecc... sono aspetti che rivestono un ruolo altrettanto importante.

Tipo ?
Esempi se ne possono fare a bizzeffe. Se l'Atom costasse di più (sui costi di produzione non ne dubito, ma poi dipende dal prezzo a cui lo vende Intel), significherebbe rinunciare ad una fotocamera migliore, un display più definito, l'ultima versione di BT, una confezione più ricca di accessori...