Intel negli smartphone? Non è un problema, secondo ARM

Scusami, hai letto i valori di consumo riportati da Anand? Sono _inferiori_ a quelli di un un dual core A9 @ 1.2 Ghz, mentre le prestazioni dell'Atom sono superiori.

Scusami, hai letto i valori di consumo riportati da Anand? Sono _inferiori_ a quelli di un un dual core A9 @ 1.2 Ghz, mentre le prestazioni dell'Atom sono superiori.




Non mi riferivo a questo, quanto al fatto che anche il core "RISC" interno ormai non è più riferibile come tale, e nelle letteratura sono anni che si accenna a "post-RISC" o termini simili. Il motivo è duplice:
- da un lato, le micro-operazioni che vendono eseguite dal core sono molto più potenti rispetto alle semplici load/store/arithmetic, e quindi anche la micro-ISA interna è più flessibile / compatta rispetto a una RISC pura (alcune microistruzioni fanno un read-modify-write del dato, effettivamente equivalendo a 3 operazioni RISC). Intel e AMD usano terminologia differente e a volte confusionaria, ma entrambe si sono mosse in questa direzione ormai da anni;
- tutte le istruzioni vettoriali (SIMD) aggiunte nel corso del tempo hanno esteso moltissimo l'ISA originaria, e la micro-ISA interna è stata estesa alla stessa maniera. In definitiva, la "vecchia" definizione di x86 = decoder CISC + core RISC non è più accurata come ai tempi del PPro / K6 (anche se rimane una buona approssimazione).


E' un incubo solo per il decoder, tutti gli altri stage possono lavorare al meglio delle proprie capacità. Anzi, forse anche di più, in quanto il codice CISC ha una compattezza irragiungibile per quello RISC, portando a un migliore utilizzo della cache istruzioni.


L'ISA esterna, dal punto di vista dei consumi, è quasi irrilevante, o per lo meno pesa molto di meno di quello che si voglia far credere. Consiglio questo thread molto interessante: http://www.realworldtech.com/forums...FTOKEN=49190965

Certo, poi ci sono casi e casi: Larrabee, con i suoi 48 core, avrebbe pagato uno scotto abbastanza salato per 48 decoder, ma era un caso particolare. Inoltre Intel si è già mossa con decisione per eliminare l'overhead dato dai decoder, rimuovendo la loro funzione dal critical path della maggior parte delle istruzioni: si guardo il Loop Detector nei processori di classe Nehalem e, soprattutto, la Trace Cache dei Sandy Bridge (capace, a detta di Intel, di eliminare la necessità del decoder nell'80% dei casi).



Le vecchie istruzioni arcaiche sono microcodate, e non vanno ad appesantire né i decoder veri e propri, né il core di esecuzione stesso. La maggior produzione di calore dei chip Intel è dovuta alle alte prestazioni messe in gioco, il cui aumento non è sempre lineare (per capirci: raddoppiare le prestazioni di un processore potrebbe richiedere un aumento >2X della produzione di calore). E' anche per questo che le nuove regole di design di Intel prevedono l'implementazione di una nuova feature solo se il rapporto prestazioni/calore è di 2:1 in favore delle prestazioni.

Infine, un ultimo test in cui un dual core A9 viene confrontato con altri processori x86 in ambiente Linux: http://www.phoronix.com/scan.php?pa...rd_es&num=4

Come potete vedere, l'A9 viene nettamente superato dal più lento degli Atom in praticamente tutti i test. Certo, l'Atom in questione consuma di più, ma il Medfield oggetto della news di hardware upgrade mantiene più o meno le stesse alte prestazioni, consumando però _meno_ di un SoC ARM.

Un'ultima nota: tutto questo non significa che la piattaforma Intel avrà successo. Ci sono mille altri motivi, molto più seri (di cui solo alcuni tecnici), per i quali potrebbe non essere adottata. Semplicemente, quello che voglio dire è che l'ISA x86 non è un fattore così penalizzante come si voglia far credere, per lo meno dal punto di vista dei consumi.

Ciao.

Scusami, hai letto i valori di consumo riportati da Anand? Sono _inferiori_ a quelli di un un dual core A9 @ 1.2 Ghz, mentre le prestazioni dell'Atom sono superiori.

a9 a 45 nanometri, medfield a 32.

a 32 nm fai un a15 che consuma come un A9, con il 50% di prestazioni in più in integer e 7 volte le prestazioni in FP

è bello fare i bench come fanno loro, eliminando i casi reali

invece un arm a 500 mhz se la giocava con un atom a 1,6 ghz e questo grazie ai vari chip acceleratori dell'arm

è chiaro che se si testa solo la cpu nuda e cruda sembra che arm perda

alla fine l'atom un chip di decodifica h264 non ce l'ha, arm si e nei casi pratici vince arm

poi se intel riuscirà a fare altrettanto, infilando chip acceleratori nel die della cpu allora potrà competere seriamente

molto interessante, mi piacerebbe capirne di più, hai qualche link da segnalarmi per avere le basi sull'argomento?

Ma gli omap4 della Texas Ins. ci sono in commercio in qualche dispositivo?

io sinceramente tifo per ARM per i seguenti motivi:

1 - ARM è una architettura nuova, efficiente e con molti margini di crescita, mentre la x86 è una
ISA oramai vecchia di 30 anni

2 - La x86 ha fatto fortuna soprattutto grazie alla sua commercialità ed al monopolio che INTEL
già aveva sul desktop.Questo gli ha permesso di fare prezzi più bassi e di diffondersi anche
nei server e SUPERCOMPUTER a scapito di altre piattaforme molte delle quali, a mio giudizio,
tecnicamente migliori. E ciò secondo me è stato a lungo andare un danno per la tecnologia,
soprattutto in termini di consumi energetici.

3 - Spezzare il monopolio di INTEL e avere una maggiore concorrenza sul mercato non può che
essere un fatto positivo per un più veloce sviluppo tecnologico. Ricordo che ARM progetta
solo i singoli core dando poi in licenza la tecnologia con le relative specifiche (numero
max di core in una CPU, max freq. di clock ec..), mentre i produttori sono tanti. insomma, è
un modello di buisiness secondo me più libero e garantista rispetto quello di INTEL.

Ribadisco che queste sono solo mie opinioni personali, chiunque e libero di non condividerle...

è bello fare i bench come fanno loro, eliminando i casi reali

invece un arm a 500 mhz se la giocava con un atom a 1,6 ghz e questo grazie ai vari chip acceleratori dell'arm

Intel con Android 4.01