RSS

Site menu

News topics
Web Rumors [9]
Il chiasso prodotto dal web...
Thech News [5]
Le novità dell'Hi Tech.
Hardware [3]
Hardware's new entries
Software [11]
Il mondo del software secondo me.
Grafica&Design [6]
Photoshop, Gimp.
Hacking e Programmazione [4]
W l'OpenSource

News calendar
«  November 2008  »
SuMoTuWeThFrSa
      1
2345678
9101112131415
16171819202122
23242526272829
30

Login form

Search

Our poll
Com'è il mio sito?
Total of answers: 70

Site friends


Total online: 1
Guests: 1
Users: 0
   
Welcome, Guest Friday, 2020-02-21, 5:36 AM

Main » 2008 » November » 2 » Intel Nehalem: uno sguardo alla nuova architettura
Intel Nehalem: uno sguardo alla nuova architettura
11:04 PM

L'approccio di Intel: Tick-Tock

Nehalem è il nome in codice con il quale vengono indicate le nuove generazioni di processori Intel, attese in versioni per sistemi desktop, server e notebook con i primi modelli al debutto nel corso del mese di Novembre. Sappiamo che le prime cpu Nehalem che verranno commercializzate da Intel prenderanno il nome di Core i7 e saranno specificamente destinate a sistemi desktop di fascia medio alta; al momento stiamo analizzando questi processori in redazione ma non ci è possibile fornirne alcun tipo di dettaglio prestazionale prima del lancio ufficiale.

loghi.jpg (39212 bytes)

Con questo articolo, il primo di una serie incentrata sulle nuove cpu Intel, vogliamo approfondire le caratteristiche architetturali di questi processori: questo articolo servirà quale riferimento tecnico per meglio interpretare i risultati prestazionali ottenuti da questi processori a confronto con le soluzioni Intel Core 2 Quad attualmente in commercio. L'importanza delle cpu Nehalem è molto elevata per Intel: parliamo infatti di un'architettura completamente nuova, che si differenzia in modo sensibile da quanto implementato da Intel con le soluzioni della famiglia Core 2.

tick_tock.gif (33533 bytes)

Il produttore americano segue un approccio noto con i termini Tick e Tock. Ogni anno Intel presenta una nuova generazione di processori, che possono o implementare un'architettura completamente nuova oppure essere costruiti utilizzando una nuova tecnologia produttiva più sofisticata rispetto a quanto in precedenza disponibile. Prendendo come riferimento le cpu Nehalem, a queste corrisponde una fase Tock, cioè quella di una nuova generazione di microarchitettura completamente differente rispetto alla precedente. Lo stesso era accaduto 2 anni fa con il debutto delle cpu della famiglia Merom, che hanno poi preso il nome commerciale di Core 2 Duo e Core 2 Quad a seconda delle versioni; in quel caso il cambio architetturale è avvenuto in sostituzione delle cpu Pentium D.

Le fasi Tick indicano l'utilizzo di un nuovo processo produttivo: le cpu Nehalem sono costruite con tecnologia a 45 nanometri, la stessa adottata dalle cpu della famiglia Penryn (Core 2 Duo e Core 2 Quad) attualmente disponibili in commercio. Alla fase Tick corrisponde tipicamente anche un refresh dell'architettura, con l'implementazione di alcune funzionalità complessivamente considerate minori; ad esempio, con le cpu Penryn ha debuttato la tecnologia produttiva a 45 nanometri e contestualmente sono state introdotte le istruzioni SSE4 non presenti nelle soluzioni della famiglia Merom. L'evoluzione a 32 nanometri di tecnologia produttiva delle cpu Nehalem è nota con il nome di Westmere; i processori di questa famiglia debutteranno non prima della fine del prossimo anno, anche in questo caso con presumibili innovazioni e migliorie ma senza stravolgimenti dell'architettura.

Per quale motivo Intel ha scelto di presentare le proprie soluzioni con questo tipo di cadenza? L'alternativa potrebbe essere quella di introdurre nuove architetture di processore congiuntamente ad un nuovo processo produttivo, ma questa strada è ricca di numerose variabili che possono pregiudicare la riuscita di un progetto e storicamente non è stata quasi mai adottata. La scelta è quindi quella di presentare nuove architetture utilizzando tecnologia produttiva avviata da tempo, con la quale non si corrono rischi particolari di rese inferiori alle aspettative, utilizzando per i processi più sofisticati architetture che sono già state evolute e sviluppate da tempo.

Architettura dell'engine: il cuore delle cpu Nehalem

Analizziamo ora l'architettura dei core contenuti nelle cpu Nehalem partendo da quelli che sono i principali elementi dell'architettura Core 2 di Intel; vedremo come Intel abbia scelto di non stravolgere quell'approccio con le cpu Nehalem, a differenza di quanto accaduto con Core 2 rispetto all'architettura NetBurst delle cpu Pentium 4 e Pentium D, operando nella direzione di un affinamento di quanto di valido era presente in Core 2.

architettura_core.jpg (49872 bytes)

Le cpu della famiglia Core hanno per la prima volta implementato una Execution Unit a 4 vie, capace quindi di eseguire sino a 4 operazioni di decode, rename e retire per ogni ciclo di clock. Questa potenza elaborativa teorica a disposizione delle cpu Core è stata difficilmente sfruttata a fondo dal codice disponibile sul mercato: per questo motivo Intel è intervenuta in Nehalem, espandendo il più possibile i buffers interni così da incrementare le condizioni nelle quali il notevole parallelismo interno di questa architettura potesse venir sfruttato al meglio. Vedremo in seguito come questo rivesta implicazioni dirette anche sulla tecnologia Hyper-Threading, a sua volta fortemente influenzata dall'integrazione del memory controller.

Nelle cpu Core 2 Intel ha introdotto le cosiddette Macrofusion: si tratta della possibilità di gestire le istruzioni TEST/CMP seguite da un conditional branch, così che possano venir decodificate, eseguite e ritirate come se si trattasse di una singola istruzione. In Nehalem Intel ha mantenuto questa interessante funzionalità estendendola ad altre tipologie di condizioni riassunte nello schema seguente:

macrofusonnew.jpg (15132 bytes)

Con le architetture Core 2 le Macrofusion potevano venir eseguite solo con applicazioni a 32bit; in Nehalem questa funzionalità è stata estesa anche al codice a 64bit. Previsti dunque incrementi prestazionali con applicazioni di questo tipo in Nehalem rispetto a quanto ottenibile con le architetture della famiglia Penryn.

Un'altra delle caratteristiche del front end del processore Nehalem mutuata dall'architettura delle cpu Core 2 è il Loop Stream Detector, logica interna al processore responsabile di individuare la presenza di loop nel software che viene eseguito. Nel momento in cui il software esegue un loop, il Loop Stream Detector (LSD) interviene sospendendo le operazioni di stima delle branches e inviando le istruzioni direttamernte dal LSD.

lsd_1.jpg (15265 bytes)

lsd_2.jpg (18261 bytes)

Nelle architetture Core 2 l'LSD è stato inserito tra Fetch e Decode, con una capacità massima di 18 istruzioni; nelle soluzioni Nehalem è stato spostato oltre la fase di decode, potendo memorizzare sino a 28 Micro-Ops all'interno dell'LSD con quindi una capacità complessiva più elevata che con le soluzioni Core 2. Oltre a gestire più istruzioni contemporaneamente attraverso il Loop Stream Detector, la nuova implementazione adottata da Intel nelle cpu Nehalem permette di disabilitare un maggior quantitativo di logica rispetto a quanto fatto con le cpu Core 2, intervenendo anche sul decode: questo ha positive ripercussioni in termini di consumo complessivo del sistema.

Altre migliorie sono state introdotte a livello dei branch predictor, componente di elevata efficienza nelle architetture Core 2. Intel ha implementato in Nehalem un secondo livello di TLB che è più lento di quello di primo livello ma può analizzare uno storico di più ampia portata, specializzato soltanto in small page (4k) Sono stati inseriti anche dei branch predictor per la cache L2, particolarmente utili secondo quanto anticipato da Intel per velocizzare alcune tipologie di applicazioni quali i database. Sono state implementate ulteriori ottimizzazioni a livello del renamed return stack buffer: questo impedisce che si possano venire a creare delle corruzioni nel return stack, componente che tiene conto in quale locazione di memoria il processore dovrà iniziare ad eseguire le proprie elaborazioni, anche nel caso in cui vi sia stata una errata previsione circa le istruzioni da elaborare all'interno della pipeline da parte dei branch predictor.

execution_engine.jpg (53906 bytes)

Le execution unit delle cpu Nehalem sono molto simili a quanto implementato da Intel nelle soluzioni Core 2: nelle cpu Penryn Intel ha implementato Execution Unit a 4 livelli, supporto SSE a 128bit e tecnologia Super Shuffle. In Nehalem a questo si aggiungono incrementi nella dimensione di varie data structure all'interno del processore, oltre che dell'out of order scheduling window.

execution_engine_2.jpg (47869 bytes)

Altre innovazioni sono state introdotte a livello di Reservation Station, passate dalle 32 delle cpu Core 2 alle attuali 36; i load buffers sono incrementati da 32 a 48 e lo stesso vale per gli store buffers, passati dai 20 delle cpu Core 2 agli attuali 32. Analizzando nel complesso l'execution engine unitamente al front end delle cpu Nehalem se ne ricava come conclusione che Intel ha scelto di non incrementare l'ampiezza di elaborazione del core nelle cpu Nehalem rispetto a quanto a disposizione con le cpu Core 2, ma di essere intervenuta per fare in modo che questa ampiezza di elaborazione dell'architettura venga sfruttata al meglio eliminando vari potenziali colli di bottiglia interni che minimizzano le prestazioni.

Alcune considerazioni

die_2.jpg (60188 bytes)
particolare di un wafer di processori Core i7

Concludiamo questa prima analisi architetturale delle caratteristiche tecniche delle cpu della serie Nehalem, in attesa di poterne misurare le prestazioni. Nel corso dei prossimi giorni scadrà l'embargo sulle prestazioni velocistiche delle cpu Core i7, le prime della famiglia Nehalem attese al debutto sul mercato: potremo quindi meglio analizzare le potenzialità di queste cpu utilizzando quale background questa analisi architetturale.

Un elemento particolarmente interessante emerso nel corso di incontri con Intel sull'architettura delle cpu Nehalem è quello legato ai trade off tra prestazioni e consumo. Nella fase di progettazione di questa nuova architettura il team di sviluppo delle cpu Nehalem ha potuto implementare nuove funzionalità solo a condizione che queste introducessero un incremento del consumo dell'1% per non meno del 2% di incremento delle prestazioni, a testimonianza di come nelle attuali e future architetture di processore sviluppate da Intel il rapporto tra prestazioni e consumo complessivo rivesta un ruolo estremamente importante.

Nel corso delle prossime settimane pubblicheremo differenti articoli sulle cpu Core i7, incentrati non solo sulle cpu ma sull'intera piattaforma a queste abbinate. Dopo questo articolo architetturale e l'analisi prestazionale delle 3 versioni di cpu Core i7 attese al debutto a Novembre, procederemo con un articolo specifico sul memory controller triple channel, analizzando le differenze prestazionali ottenibili con questi processori al variare sia del tipo di memoria che del numero di moduli memoria utilizzati.

finale.jpg (27478 bytes)
731 milioni di transistor in palmo di mano

A seguire, introdurremo un confronto prestazionale sulle schede video top di gamma ATI e NVIDIA in abbinamento a processori Core i7, con architetture SLI e Triple SLI a confronto con differenti versioni di configurazioni ATI CrossfireX, sfruttando in questo le schede madri basate su chipset Intel X58 compatibili con entrambe le tecnologie multi GPU. A chiudere, una serie di analisi prestazionali di schede madri per processori Intel Core i7 basate su chipset Intel X58 nel frattempo giunte in redazione.

Intel ha reso disponibili, negli ultimi mesi, alcuni documenti incentrati sull'architettura delle cpu Nehalem; per chi volesse approfondire ulteriormente l'analisi di questa nuova generazione di processori abbiamo messo a disposizione un archivio contenente questa documentazione in formato pdf, scaricabile da questo link.

Category: Hardware | Views: 828 | Added by: koelio | Rating: 0.0/0 |
Total comments: 2
0
2 Pumza  
I don't know what they've been doing with GSM but it makes me whole desktop slow. If I sctiwh to the workspace that I have the GSM window on there is some annoying lag, same with resizing the window which is so slow that I can count the times it redraws the window. It does it even without the Resources tab being visible (so I don't think it's the graph-drawing that causes it). Starting up seems to take a while to I don't even care about the CPU usage, right now I'd much rather fire up a terminal and run top.I've brought the slow window issue up in IRC and was told something along the lines of that's just GTK+ being slow', which makes me why no other GTK+ apps I run do this.

0
1 Ravi  
essential idle . I never said ceopletmly idle. When GSM was not running, my CPU load was 1-3% consistently, as monitored through good ol' top. And having a lot of long running and leaky applications open tends to consume a lot of memory but that doesn't mean they're churning CPU (and they weren't). GSM is alone eating around 20% CPU just by being open.It turns out that the majority of this churning is from its process listing updating and resorting, exposing a bunch of issues with the GtkTreeView. The graphs at this point are only partly to blame, but have been greatly optimized in trunk. The current focus needs to be fixing the process listing.

Name *:
Email *:
Code *: