Sino a 8 core per le future CPU Intel della famiglia Atom

[Redazione di Hardware Upg]

Link alla notizia: http://www.hwupgrade.it/news/cpu/sin...tom_44257.html

L'utilizzo di processori Atom in sistemi server di elevata densità e ridotto consumo alla base della futura evoluzione di queste CPU, destinate a venir proposte anche in versioni a 8 core

Click sul link per visualizzare la notizia.

[JackZR]

Presto nei vostri smartphone!

[demon77]

Otto core? Mi pare un perfetto controsenso in un Atom.
Che me ne faccio? Mica devo fare rendering. Allora piuttosto fanne due più potenti e con clock variabile.

[illidan2000]

non ho capito cosa significhi "Cpu di tipo out of order"...

[coschizza]

Originariamente inviato da demon77

Otto core? Mi pare un perfetto controsenso in un Atom.
Che me ne faccio? Mica devo fare rendering. Allora piuttosto fanne due più potenti e con clock variabile.

invece è perfetto se ti serve piu potenza allora non ha senso comprare un server basato su atom ma uno basato sugli xeon che hanno modelli a basso consumo e prestazioni superiori, per gli altri piu core significa piu thread paralleli e quando non servono possibilità di spegnerli e consumare davvero un nulla sia perche i core vengono disattivati sia perche i soc contiene gran parte della scheda madre di un normale pc quindi anche l'intero ssitema va a disattivarsi in casi di non utilizzo. Fare meno core piu potenti è un controsenso per il campo di utilizzo dove vanno a operare perche significa avere dei core che difficilmente andranno a spegnarsi essendo comunque pochi a dover gestire piu thread paralleli quindi a conti fatti passare agli xeon è molto piu intelligente se le esigenze sono queste.

Questo soc arm serve per contrastare il futuro utilizzo di soc arm in micro server di questa categoria che anche loro saranno simili come numero di core che contenuto di porte direttamente nel soc.

[coschizza]

Originariamente inviato da illidan2000

non ho capito cosa significhi "Cpu di tipo out of order"...

http://en.wikipedia.org/wiki/Out-of-order_execution

[maxmax80]

Originariamente inviato da coschizza

invece è perfetto se ti serve piu potenza allora non ha senso comprare un server basato su atom ma uno basato sugli xeon che hanno modelli a basso consumo e prestazioni superiori

infatti hai centrato il succo del discorso: le tecnologie Atom & Xeon in futuro saranno destinate a fondersi in un unico prodotto, performante & a basso consumo!


intanto la discriminante per questi nuovi atom sarà -come sempre- il prezzo..

anzi, oggi più che mai intel non si può più permettere di imporre prezzi da fuori di testa, visto che un pochino la crisi si fa sentire anche nei loro bilanci..

[WarSide]

Originariamente inviato da coschizza

Questo soc arm serve per contrastare il futuro utilizzo di soc arm in micro server di questa categoria che anche loro saranno simili come numero di core che contenuto di porte direttamente nel soc.

Esatto

Un webserver non ha bisogno di potenza bruta ad esempio, si potrebbero fare cluster che consumano pochissimo con nodi da accendere solo quando ci sono picchi.

Ma ci sono tanti altri servizi che non necessitano di chissà quanta potenza e già girano su atom...

[Sevenday]

Originariamente inviato da maxmax80

infatti hai centrato il succo del discorso: le tecnologie Atom & Xeon in futuro saranno destinate a fondersi in un unico prodotto, performante & a basso consumo!


intanto la discriminante per questi nuovi atom sarà -come sempre- il prezzo..

anzi, oggi più che mai intel non si può più permettere di imporre prezzi da fuori di testa, visto che un pochino la crisi si fa sentire anche nei loro bilanci..

Speriamo; ma ad oggi i prezzi delle CPU attuali (medie e top di gamma) non mi sembrano tanto economiche.

Appena vedo scritto ATOM però risvegliano brutti ricordi...

[coschizza]

Se qualcuno si chiedesse che server usaranno questo tipo di soc la risposta potrebeb sembrare ironica perche fra i tanti vi è uno leader del mercato che è stato comprato da AMD.

vi riporto al loro sito con un prodotto preso come esempio che monta svariete centinaia di soc arm attuali e che saranno espansi con questi modelli in futuro per raggiungere quindi anche le migliaia di core tutti in un singolo rack.

http://www.seamicro.com/node/212

[illidan2000]

Originariamente inviato da coschizza

http://en.wikipedia.org/wiki/Out-of-order_execution

si, ma da quello che si legge, dagli anni 70 in poi dovrebbero essere tutte così.
che senso ha ribadire il concetto?

[coschizza]

Originariamente inviato da illidan2000

si, ma da quello che si legge, dagli anni 70 in poi dovrebbero essere tutte così.
che senso ha ribadire il concetto?

Non tutti per esempio fino a poco fa tutti gli arm erano in-order e solo dall'A9 sono passato la nuovo sistema anche l'atom è nato cosi per mantenere i consumi piu bassi possibile e lui passera nel 2013.

Dipende dall'utilizzo che ne fai e questo vale per utte le cpu in circolazione anche quelle ibm spark ecc sono state in order in varie generazioni dipende dallo scopo finale dal tipo di prestaioni e consumi che devi raggiungere.

Ti faccio un esempio la xbox 360 ha una cpu ibm cor 3 core in order farli out of order singificava occupare piu spazio e a parità di die avresti avuto solo 2 core ma piu performanti, visto l'utilizzo è stata scelta la prima soluzione.

Un altro esempio le cpu oracle/sun SPARC sono state sempre in order dino al 2011 con la SPARC T4 la prima out of order.

[io78]

@illidan2000

che atom e un dei pochi se non l'unica cpu moderna che non segue il principio out-of-order

[coschizza]

Originariamente inviato da io78

@illidan2000

che atom e un dei pochi se non l'unica cpu moderna che non segue il principio out-of-order

anche la prossima intel Xeon Phi la scheda coprocessore usa circa 60 core x86 in order per funzionare.

[yankeeone]

bah,
É da un mesetto che ho sostituito il mio "vecchio" debian server con atom dual core 330 (d945gclf2 2gb ram) con una nuova fiammante odroid-x con processore ARM7L (stesso SoC del galaxy s3) quad core con 1gb ram sul quale gira debian 7 wheezy con kernel 3.6.2 (finalmente ottimo supporto).
Per le funzioni che deve fare (videosorveglianza, server samba, torrentserver, webserver) non mi fa per niente rimpiangere l'atom. anzi, prima il consumo stava sui 45/55W, ora oscillo tra 6/10W.
Quando verrá inserito nel kernel anche il supporto allo scaling di frequenza per cpu,gpu,ram sará ancora meglio.
per ora cmq non mi lamento.... anzi!
ciao ciao atom!

[coschizza]

Originariamente inviato da yankeeone

bah,
É da un mesetto che ho sostituito il mio "vecchio" debian server con atom dual core 330 (d945gclf2 2gb ram) con una nuova fiammante odroid-x con processore ARM7L (stesso SoC del galaxy s3) quad core con 1gb ram sul quale gira debian 7 wheezy con kernel 3.6.2 (finalmente ottimo supporto).
Per le funzioni che deve fare (videosorveglianza, server samba, torrentserver, webserver) non mi fa per niente rimpiangere l'atom. anzi, prima il consumo stava sui 45/55W, ora oscillo tra 6/10W.
Quando verrá inserito nel kernel anche il supporto allo scaling di frequenza per cpu,gpu,ram sará ancora meglio.
per ora cmq non mi lamento.... anzi!
ciao ciao atom!

hai ragione ad aver cambiato ma non è mica l'atom che consuma quei W non puoi confrontare un soc con un sistema classico dove i consumi sono dati vari componenti non presenti nel soc del processore. Cioè non è un problema del processore ma della piattaforma completa. Cioè confronti un sistema simile desktop con il ODROID-X che è un sistema per sviluppo mobile. mobile

Quindi per il tuo utilizzo ti servirebbero gli ultimi soc atom che hanno un tdp confrontabile con il sistema che hai usato tu.

[jappilas]

Originariamente inviato da illidan2000

si, ma da quello che si legge, dagli anni 70 in poi dovrebbero essere tutte così.
che senso ha ribadire il concetto?

non proprio
si dice che agli anni 70 risalgono i primi studi sull' esecuzione out of order delle istruzioni, a livello accademico... ma prima di avere processori OoOE funzionanti, anche già nel settore mainframe e delle workstation RISC (dove la maggiore regolarità e semplicità della ISA - e quindi della pipeline della cpu - favoriva l' applicazione di tecniche implementative più sofisticate - o dove l' esigenza di prestazioni assolute "a qualunque costo", la richiedeva) c'è voluto un certo tempo
ancor più per vedere i primi processori out of order di fascia mainstream nonchè CISC come cyrix 6x86, pentium pro, amd k6, tutti della metà degli anni 90..
il fatto è che passare da un' architettura in order a una out of order non è un' operazione immediata
la prima è sequenziale e sincrona - ogni istruzione è eseguita (*) se e solo se è completata l' esecuzione di quella che la precede nel programma, il che vuol dire che ad ogni operazione in memoria la pipeline si ferma (per parecchi nanosecondi, corrispondenti a parecchi cicli di clock in cui la cpu avrebbe potuto eseguire altro) in attesa del dato
è facile vedere come in questo caso (magari con un processore basato su una isa complessa, che per dire preveda un forte uso dello stack per via della carenza di registri...) sia più problematica e possiiblmente meno efficace l' implementazione di un eventuale parallelismo hw - per sfruttare il quale in maniera ottimale occorrerebbe poter lavorare sempre su coppie (o n-uple) di operazioni non dipendenti tra loro (cioè il risultato della prima richiesto dalla seconda), e con il meno possibile di accessi in memoria ...

ora, la seconda richiede di ripensare la pipeline in ottica dataflow - le istruzioni sono caricate in ordine di programma, eseguite se e quando sono disponibili gli operandi (in maniera asincrona), e infine "ritirate" (finalizzate, con risultati salvati nei registri, o in certi casi scartate - se una condizione da cui dipendeva il branch in cui ricadono si rivela poi falsa ) di nuovo in ordine di programma
cosa che serve a mantenere la correttezza nell' esecuzione dello stesso (che non è più implicitamente assicurata come nel caso precedente) e per cui nel caso della OOOE occorre logica (quindi transistor) per il tracciamento e riordino dopo l' esecuzione
oltre alla logica e alle strutture dati (complesse) necessarie per bufferizzare a monte delle alu, una "instruction window" più o meno ampia, sbrogliare le dipendenze all' interno di questo, tenere registri interni in soprannumero e tracciare quelli rinominati (magari anche disaccoppiarli ad esempio in modo che il set visibile all' istruzione/operazione attuale sia separato dal set globale, e in questo copiato solo al momento della finalizzazione) accodare (altrimenti si rischiano stalli con perdita di efficienza) le operazioni collaterali risultanti dall' esecuzione ...

tutti dettagli che contribuiscono in positivo alla complessità architetturale e alla quantità di transistor da integrare
che per certe applicazioni e/o in certe condizioni (ad esempio, se so che il codice che verrà eseguito ha una elevata regolarità, o non sono determinanti le prestazioni pure ma piuttosto il restare entro un certo budget energetico) si può scegliere di non implementare - anche se siamo nel 2012..

[CrapaDiLegno]

I transistor usati per l'esecuzione OoO sono facilmente rimpiazzabili da compilatori ottimizzati. Ecco perché le console non hanno unità OoO. L'HW è noto, il flusso del programma pure, e quindi il compilatore può eseguire le stesse ottimizzazioni che farebbe l'HW al momento dell'esecuzione, ordinando le istruzioni in maniera efficiente.
L'OoO HW serve per garantire la libertà di implementazione dell'architettura, così che su una architettura la sequenza è ordinata al volo in una maniera e su un altra in maniera diversa, in entrambi i casi tentando di massimizzare il throughput.
Inoltre l'OoO vale su architetture con pipeline lunghe, là dove attendere l'esecuzione completa richiede molti cicli di clock. Su pipeline corte è possibile che lo spreco dei transistor per ottenere l'esecuzione OoO non valga la pena, e anzi sia meglio fare una pipeline parallela che può eseguire in maniera autonoma altro codice non dipendente da quello in esecuzione sulla prima.
In alcuni contesti, conoscere esattamente i tempi di esecuzione di una operazione è importante, per cui molti microcontrollori mantengono l'esecuzione in order.
A seconda delle architetture e dei campi di utilizzo un approccio è migliore di un altro.

[jappilas]

Originariamente inviato da CrapaDiLegno

I transistor usati per l'esecuzione OoO sono facilmente rimpiazzabili da compilatori ottimizzati.

facilmente, proprio no
l' esecuzione fuori ordine è fatta per massimizzare lo sfruttamento delle risorse di calcolo (rifornirle continuamente di dati da elaborare) in presenza di accessi in memoria/IO (che altrimenti bloccherebbero una pipeline sequenziale) e dei fattori da cui dipende l' esecuzione in ogni dato momento, tipicamente noti non al momento di compilare il programma, nè di installarlo, ma all' ultimo durante l' esecuzione...
e lì il compilatore non ha modo di arrivare e adottare accorgimenti (a meno non sia un jit, ma un jit ha un certo overhead), così come ben difficilmente da solo può mitigare l' effetto di un accesso in memoria con annessa latenza...

Ecco perché le console non hanno unità OoO.

sulle console è più che altro una questione di costi (trattandosi di giocattoli, peraltro veduti inizialmente sotto costo) e di transistor budget (non va dimenticato che inizialmente xenon e xenos erano inizialmente due chip separati, e che in Cell la maggior parte del silicio è preso non dal core PPC ma dalle SPE di contorno - per non parlare del fatto che la prima xbox montava un P6 coppermine seppur con metà L2C...)

L'HW è noto, il flusso del programma pure, e quindi il compilatore può eseguire le stesse ottimizzazioni che farebbe l'HW al momento dell'esecuzione, ordinando le istruzioni in maniera efficiente.

sulle console l' hw (quantomeno il suo comportamento e la sua forma logica, per come appare al sw) è noto - ma soprattutto immutabile (per quel modello) di modo che io programmatore posso calibrare i miei algoritmi e soprattutto il working set in modo da ottenere un certo framerate e contare sul fatto che funzioni allo stesso modo su tutte le console di quel modello, presenti e future (anche più miniaturizzate, che consumino meno ecc) - ma il flusso del programma no, per i motivi di cui sopra

L'OoO HW serve per garantire la libertà di implementazione dell'architettura, così che su una architettura la sequenza è ordinata al volo in una maniera e su un altra in maniera diversa, in entrambi i casi tentando di massimizzare il throughput.

serve a massimizzare il throughput sì, ma in presenza di condizioni di lavoro dinamiche e non note e gestibili a priori, più che per compensare le peculiarità e idiosincrasie delle specifiche implementazioni - che possono averne anche essendo cpu OoO
per cui la covenienza di applicare ottimizzazioni statiche a priori, si ha comunque...
riprendo un esempio dall' altro thread:
Core e Core 2 sono (micro)architetture della stessa famiglia con parecchie similarità, entrambe dotate di esecuzione fuori ordine
eppure, siccome il primo è dotato di un decoder derivato dal P6, superscalare a 3 vie ma capace di decodificare 3 istruzioni in una passata a patto che siano tutte e tre semplici -traducibili in una sola microop- o una complessa -traducibile in una serie di fino a 4 microop- seguita da due semplici, mentre nel secondo il decoder è a 4 vie ma soggetto a una limitazione analoga
far eseguire a ciascuna il codice ottimizzato per l' altra produce una situazione subottimale (cicli in cui si decodifica un' istruzione alla volta finchè quella complessa è allineata al complex decoder)

Inoltre l'OoO vale su architetture con pipeline lunghe, là dove attendere l'esecuzione completa richiede molti cicli di clock. Su pipeline corte è possibile che lo spreco dei transistor per ottenere l'esecuzione OoO non valga la pena,

Pentium PRO aveva una pipeline OoO a 10 stati, AMD K6 una OoO a 6 stadi, Atom ha una pipeline in order a 16 stadi
tra i non x86, DEC Alpha 21264 funzionante da 500 Mhz (per l' epoca una frequenza elevatissima) a un ghz, aveva una pipleline ooo a 7 stadi
il numero di stadi dipende dalla strutturazione della pipeline (a sua volta dipendente dalla ISA e dall' approccio scelto per implementarla) in funzione della frequenza target (dal momento che la pipeline può lavorare alla frequenza raggiungibile dallo stadio più lento, spezzare stadi complessi in stadi più semplici può permettere di salire in frequenza)
ma da solo non c' entra nulla con l' usare o meno l' esecuzione in order piuttosto che ooo...

e anzi sia meglio fare una pipeline parallela che può eseguire in maniera autonoma altro codice non dipendente da quello in esecuzione sulla prima.

questo ha un nome, itanium - o in generale VLIW con programmazione esplicita del parallelismo (epic)
avrai notato che dopo un iniziale entusiasmo, di itanium (o di processori vliw in genere) non si sente più parlare... il motivo è che nonostante le promesse di elevate prestazioni, si è notato che lo sforzo richiesto al programmatore per ottenerle (analizzare le dipendenze tra istruzioni e scriverle a coppie nei bundle , a mano..) era troppo elevato, e solo pochi avevano effettivamente le competenze e le capacità per farlo in modo che il codice girasse su itanium con prestazioni superiori a quanto ottenibile in meno tempo e con tool standard, su processori general purpose
il gioco non valeva la candela...
a maggior ragione se poi i processori general purpose nel frattempo migliorano al punto da surclassare gli itanium in sostanzialmente tutti i campi che questo domina...

In alcuni contesti, conoscere esattamente i tempi di esecuzione di una operazione è importante, per cui molti microcontrollori mantengono l'esecuzione in order.

premesso che quando si progetta un sistema realtime si valuta dell' hw commisurato al sw che dovrà essere eseguito cioè capace di eseguirlo rispettando i vincoli temporali (e lasciare un certo "headroom" perchè certi algoritmi di scheduling rt con resource reservation non garantiscono un funzionamento affidabile sopra una certa percentuale di occupazione) nel worst case
ma in primis si lavora sul sw stesso di modo da dargli un comportamento il più deterministico possibile, cominciando col scegliere un kernel realtime dalle latenze documentate (che quand' anche lo sono sono sempre documentate al più nel worst case) e proseguendo con l' eliminazione alla radice del page swap in memoria virtuale, e magari delle malloc()
quindi anche per quanto riguarda le latenze hw, interessa più che siano magari elevate ma costanti (quindi prevedibili) che non che siano ridotte in senso assoluto
ma i microcontrollori mantengono l' esecuzione in order più che altro per essere semplici ed economici da produrre e integrare, più che per ridurre le latenze - che con esecuzione in order in effetti aumentano, dovendo fare i conti con accessi in memoria non mascherati, di cui attendere il completamento prima di andare avanti con il programma...

A seconda delle architetture e dei campi di utilizzo un approccio è migliore di un altro.

questa, perdonami, è un' ovvietà...