Nehalem: Execution Unit, TLBs e Unaligned Cache Accesses

L’Execution Unit, l’unità che si occupa dell’esecuzione del codice dopo la decodifica dell’istruzione, è rimasta sostanzialmente invariata rispetto a Penryn: Intel ha pensato soprattutto ad ottimizzare dimensioni e funzionamento senza stravolgere nulla in modo radicale.

Ridimensionando parte delle strutture dati, l’Execution Unit di Nehalem è ora in grado di mantenere fino a 128 Micro-ops nello stesso istante, contro le 96 di Conroe. Lo stesso principio ha portato la capacità della Reservation Station, che si occupa di incanalare le Micro-ops verso l’Execution Unit, da 32 a 36. Anche i Load e Store buffer hanno subito un incremento passando, rispettivamente, da 32 a 48 e da 20 a 32 Micro-ops.

Modifiche sono state apportate anche ai TLB: si tratta dei buffer che al loro interno memorizzano le ultime corrispondenze dirette fra indirizzi virtuali (ad esempio quelli usati dai processi e non riferibili ad un’unità fisica) e indirizzi fisici (ovvero corrispondenti ad una relativa unità fisica, come può essere la cache o la RAM), divenuti famosi a causa del noto bug che riguardava le prime CPU Phenom di AMD.

I TLB diventano unità critiche per le prestazioni di applicazioni web-server e database: Intel non si è limitata ad aumentarne le dimensioni, ma ha anche pensato ad introdurre un secondo livello, più lento del primo, ma in grado di contenere delle page table più estese.

Oltre a questo, Nehalem include anche un più efficiente algoritmo di elaborazione per quanto riguarda quelle operazioni sulla memoria che superano il limite dei 16 byte e che, quindi, presentano dati non allineati all’interno della cache.

In Conroe era difficile prevedere un caso simile, portando i compiler a considerare sempre i dati come non allineati: questo influiva sulle prestazioni in modo abbastanza rilevante, visto che l’esecuzione di operazioni allineate era significativamente più veloce.

Nehalem risolve questa situazione sotto due aspetti. Da una parte, l’esecuzione di operazioni su dati non allineati è stata ottimizzata in modo da avere un minore impatto sulle prestazioni e, nel caso il compiler abbia previsto un’operazione non allineata su dati allineati, Nehalem esegue la esegue senza alcuna perdita di performance.