Nehalem: Macro-ops e Loop Stream Detector

Già con Conroe, Intel aveva introdotto un front-end a quattro vie, in grado quindi di gestire quattro istruzioni per ogni ciclo di clock: questa scelta ha determinato un grosso vantaggio prestazionale rispetto alla precedente soluzione NetBurst. Tuttavia l’architettura di Conroe non ha permesso agli sviluppatori di sfruttare a dovere la potenza messa a disposizione dal forte parallelismo interno a causa delle dimensioni ridotte di buffer e strutture di gestione che si comportavano come un collo di bottiglia nella microarchitettura stessa.

In Nehalem, strutture e buffer sono stati potenziati in modo da non rappresentare un limite alle capacità di elaborazione dell’Execution Unit, ottimizzando alcuni meccanismi di funzionamento del data-flow interno all’architettura.

Un esempio possono essere le Macro-ops, un set di istruzioni diverse che possono essere identificate ed elaborate come fossero un’istruzione singola. Questa caratteristica era già presente in Conroe, ma con alcune limitazioni: le branch condition previste, permettevano di eseguire la Macro-ops fusion solamente su codice a 32-bit. L’aggiunta di ulteriori casi, invece, permette a Nehalem di sfruttare questa peculiare caratteristica anche su codice a 64-bit, particolare di assoluta rilevanza per chi usa applicazioni di questo tipo.

Un altro cambiamento nel data-flow si nota nel funzionamento del Loop Stream Detector, l’unità che si occupa dell’identificazione di loop consecutivi, evitando che questi vengano elaborati ogni volta da zero.

In Conroe, il LSD era inserito tra l’hardware di fetch e decode ed era in grado di immagazzinare 18 istruzioni da decodificare: questo permetteva di disabilitare solamente due dei tre stadi di elaborazione. Nehalem, invece, sposta il Loop Stream Detector dopo l’unità di decode, permettendo la sua disabilitazione in caso di istruzioni ripetute, e riesce a contenere fino a 28 Micro-ops già disponibili per l’Execution Unit.

Tra le peculiarità dell’architettura Core i7 vi è la presenza di due livelli di branch prediction, dove il secondo è caratterizzato da maggiori dimensioni e da una minore velocità, fattore questo derivante dalla sua posizione avanzata nella sequenza logica. Quando nel branch predictor di primo livello viene a mancare un dato necessario al proseguimento dell’elaborazione (data miss), questo verrà cercato in quello di II livello dove, grazie alla sua maggiore capacità, vi sono più ampie possibilità che questo sdato sia presente.

Questa scelta porta con sé più d’un vantaggio: c’è un miglioramento della gestione energetica, una diminuzione dell’intervallo d’elaborazione del loop ed un aumento della lunghezza dello stesso.