[IDF08] Intel Nehalem in-depth preview

30 reacties
Inhoudsopgave
  1. 1. Inleiding
  2. 2. Blokdiagram
  3. 3. Slimmer omgaan met instructies
  4. 4. Branch prediction en execution units
  5. 5. Terugkeer van HyperThreading
  6. 6. Geheugenmanagement
  7. 7. Caching
  8. 8. QuickPath
  9. 9. Geïntegreerde geheugencontroller
  10. 10. Virtualisatie
  11. 11. Power controller
  12. 12. Turbo modus
  13. 13. Conclusie
  14. 14. Reacties

Inleiding

Intel heeft tijdens de eerste dag van haar Developer Forum Fall 2008 veel nieuwe details bekend gemaakt over de Nehalem architectuur, waarvan later dit jaar de eerste processors op de markt zullen komen. Enkele dagen geleden werd al bekend gemaakt dat de desktop varianten van Nehalem als Core i7 door het leven zullen gaan. In dit artikel nemen we alle nieuwe details uitgebreid met je door.

Wie nog niet helemaal is ingelezen in het fenomeen Nehalem, raden we ten zeerste aan om onze Nehalem preview van enkele maanden geleden te lezen, voordat je dit artikel gaat doornemen. In deze eerdere preview hebben we de belangrijkste eigenschappen van Intels binnenkort verschijnende architectuur uitvoerig uit de doeken gedaan.

Kort samengevat is Nehalem Intels volgende Tock in de inmiddels beroemde Tick-Tock strategie. Deze houdt in dat men om-en-om iedere twee jaar een nieuwe processorarchitectuur en een nieuwe procestechnologie introduceert. Nehalem is zoals gezegd een tock en dat betekent een volledig nieuwe architectuur, op een inmiddels bestaand productieprocedé, 45 nanometer. Vanzelfsprekend is Nehalem in de basis gebaseerd op de Core-architectuur zoals we die kennen van Intels huidige processors, maar op vrijwel alle aspecten van de processor zijn er radicale vernieuwingen doorgevoerd.


Nehalem is de Tock van Intels 45 nm generatie

De belangrijkste aspecten van Nehalem zijn in onze genoemde eerdere preview uitvoerig besproken. Een van die kenmerken is dat Intel bij de nieuwe generatie CPU's de geheugencontroller heeft geïntegreerd. De eerste Nehalem varianten zullen een triple-channel DDR3-controller aan boord hebben, bij latere varianten kan het aantal kanalen verhoogd of verkleind worden. Verder zal Nehalem als native quad-core chip op de markt komen, ofwel vier cores daadwerkelijk in één chip. Ook nieuw is Intels QuickPath technologie, de opvolger van de frontside-bus, die voor snellere chip-naar-chip verbindingen kan zorgen. Ook de cache-architectuur is door Intel flink onder handen genomen. Waar bij de huidige Core 2 processors iedere core een eigen L1-cache heeft en twee cores samen L2-cache delen, zijn bij Nehalem juist de L1- én L2-cache per core ingedeeld en is er een derde cache-level (L3) die door alle cores gedeeld wordt. Daarnaast was ook al bekend dat bij Nehalem de HyperThreading technologie zou terugkeren, dat Intel een aantal nieuwe SSE 4.2 instructie toevoegt aan de architectuur en dat er in de toekomst varianten met geïntegreerde videokaart komen.

Tot zover de herhaling, nu over naar alle nieuwe informatie. Dit artikel is geschreven op basis van een presentatie die tijden het Developer Forum is gehouden. Helaas zijn de slides nog niet beschikbaar, zodat we in het artikel gebruik moeten maken van foto's. Hierdoor is de leesbaarheid van de informatie niet altijd even optimaal, waarvoor onze excuses.

Blokdiagram

Om de dieper verscholen verschillen tussen Penryn en Nehalem boven water te krijgen, werpen we een blik op het blokdiagram van de nieuwe architectuur. Op onderstaande slide zie je hoe de architectuur van Nehalem er schematisch uitziet.

Het blok linksboven zorgt voor het ophalen, queuen en decoderen van alle binnenkomende instructies. De Rename/Allocate en Reservation Station blokken daaronder passen de volgorde van de instructies daarna zo aan, dat deze op een zo efficiënt mogelijke volgorde kunnen worden uitgevoerd. De daadwerkelijke berekeningen worden uitgevoerd door de execution units. Zoals op het schema te zien is de weg van het bovenste blok tot en met het reservation station zogenaamd 4-wide, wat betekent dat er telkens vier instructies per klokslag doorgevoerd kunnen worden. Naar de execution units kunnen zelfs zes instructies per klokslag worden doorgestuurd, wat één van de eerste architecturele verbeteringen ten opzichte van Penryn is. Hier komen we verderop op terug. 

In het blokschema zien we verder dat de instructie fetchers zijn verbonden met 32 kB L1 instructiecache en verbonden aan de executions units zien we juist 32 kB L1 datacache. Beide caches staan weer in verbinding met 256 kB L2-cache die iedere core exclusief tot zijn beschikking heeft. Die L2-cache dient weer als buffer voor de onder alles cores gedeelde L3-cache. 

Op de komende paar pagina's worden de verschillende onderdelen van bovenstaand verder uitgelegd en beschrijven we wat de verschillen zijn met de bestaande core architectuur.

Slimmer omgaan met instructies

Een van de nieuwe eigenschappen van de Core architectuur was de komst van macrofusion. Om het nut hiervan te begrijpen, is enige kennis van de werking van een processor benodigd. PC processors worden aangestuurd met zogenaamde x86-instructies. Deze instructies, die in jargon macro-operations ofwel macro-ops worden genoemd, kunnen relatief simpel, maar ook zeer compex zijn. Vandaar dat een processor vóór verwerking deze macro-ops omzet naar één of meerdere, simpele micro-ops. Deze micro-ops kunnen door de executions units eenvoudig worden uitgevoerd. Het omzetten van macro-ops in micro-ops gebeurt in de instructie decoder, die we in het schema op de vorige pagina hebben gezien. Simpele macro-ops resulteren eveneens in één micro-op, sommige complexere macro-ops vergen bijvoorbeeld twee of drie micro-ops.

Processors zijn de laatste jaren echter steeds krachtiger geworden en zodoende is het soms mogelijk om twee instructies te combineren en in één keer uit te voeren. Dat is exact wat er gebeurt bij macrofusion: twee relatief simpele macro-ops die binnenkomen worden samengevoegd tot één micro-op en daardoor dus op dubbelle snelheid uitgevoerd. Zo kan de core architectuur bijvoordeeld een compare en branch instructie laten samensmelten, iets wat in veel gevallen voor een aardige prestatiewinst kan zorgen.

Bij de komst van Nehalem komt er ineens een groot nadeel van de macrofusion in de Core architectuur van de Conroe en Penryn processors bovendrijven; deze blijkt immers alleen maar te werken als de processor in 32-bit modus werkt. Vandaar dat sommige software zodra je overstapt op 64-bit Windows op bestaande Intel processors ineens een aantal procenten langzamer kan werken. Bij Nehalem werkt de marcofusion echter ook probleemloos in 64-bit modus.

Een andere flinke verbetering ten opzicht evan de Core architectuur zit hem in de zogenaamde Loop Stream Detector. Ook dit is een technologie die bij de Core architectuur voor het eerst werd geïntroduceerd. De courante Intel processors kunnen loops in programmacode van maximaal 18 instructies herkennen. Zodra zo'n loop is gedetecteerd, worden de instructies niet telkens opnieuw uit de cache of geheugen opgehaald, maar worden ze direct van een loop buffer aan de decoder doorgevoerd, zoals te zien in onderstaande slide.

Bij Nehalem zit die loop detector een stuk slimmer in elkaar. Hij heeft immers een plek áchter de instructiedecoder gekregen. Loops worden zodoende nu dus herkend op micro-op niveau. Dat betekent dus dat zodra een processor met een programmaloop bezig is, de instructies niet telkens opnieuw hoeven te worden gedecodeerd, wat heel wat overhead weghaalt en daardoor voor een aardige prestatiewinst kan zorgen. Daarnaast herkent de nieuwe loop detector series tot maximaal 28 micro-ops. Aangezien in de praktijk in de meeste gevallen iedere macro-op wordt omgezet naar één micro-op, mag je met een schuin oog dit getal vergelijken met het aantal van de core architectuur. Ofwel; de nieuwe loop detecter haalt niet alleen een extra stuk overhead weg, maar werkt ook met langere stukken code.

Branch prediction en execution units

Een belangrijke manier om de prestaties van een processor te verbeteren is het zo goed mogelijk voorspellen van vertakkingen in programmatuur. Immers; moderne processors verwerken instructies niet noodzakelijkerwijs in de volgorde waarin ze binnenkomen en daardoor kan het zijn dan er al gewerkt moet worden aan instructies die nog afhankelijk zijn van een eerdere instructie, die pas op een later tijdstip wordt uitgevoerd. Wanneer er in zo'n geval een vertakking in een programma ontstaat, zal de processor zo goed mogelijk een gok doen welke tak de meeste kans van slagen heeft. Brand predictors zijn tegenwoordig zo goed dat er nog maar zelden mis gegokt wordt. Dat is maar goed ook, want een branch miss betekent dat de hele pipeline vol kan zitten met instructies die niet meer nodig zijn en dat het heel wat klokslagen kan duren eer weer een juiste instructie uit de processor rolt.

Intel heeft op een aantal manieren de branch prediction in Nehalem verder verbeterd. Een van de belangrijkste manieren bestaat uit het al beginnen met het voorspellen zodra instructies in L2-cache aankomen. Op dit niveau heeft de processor een breder kijkveld en kan er zodoende een nog betere beslissing worden genomen.

 

Dan de execution units; zoal op de vorige pagina al beschreven is er bij Nehalem een zesvoudig pad van het reservation station naar de daadwerkelijke rekeneenheden van de core. Bij de Core architecuur waren dat er vier. Achter elk van deze zes ingangen, zitten één of meerdere rekeneenheden. Poort 2, 3 en 4 zijn alleen geschikt voor geheugenadres operaties, poort 0, 1 en 5 zijn ook geschikt voor integer of floating point berekeningen. 

De truc is natuurlijk om ten alle tijden alle vier poorten gevuld te hebben. (Het vullen van vijf of zes is in de praktijk vrijwel onmogelijk, aangezien er tot aan de reservation station slechts vier instructies per klokslag kunnen worden doorgestuurd.) Dat betekent dus dat de processor in ieder moment in tijd in het ideale geval aan de slag moet kunnen vier verschillende bewerkingen, die naast elkaar in de verschillende execution units moeten passen. Geen wonder dus dat een processor zoals eerder gezegd de volgorde van instructies omhusselt om deze in een optimalere volgorde uit te voeren. 

Om in zoveel mogelijk gevallen alle execution units bezig te houden, is bij Nehalem het aantal instructies dat een core tegelijkertijd in z'n achterhoofd kan houden om in geoptimaliseerde volgorde uit te voeren flink verhoogd. Bij de Pentium M was het maximum 64 instructies, bij de Core architectuur werd dat aantal verhoogd naar 96 en nu bij Nehalem zelfs naar 128. Een verhoging van 33% dus. De ruimte in het reservation station is toegenomen van 32 naar 36 instructies. 

Het aantal buffers voor load en store operaties is nog meer toegenomen. Het aantal load buffers gaat van 32 naar 48, het aantal store buffers van 20 naar 32. Opnieuw kan dit allemaal in veel gevallen voor aardige prestatiewinsten zorgen.

Terugkeer van HyperThreading

In onze eerdere preview beschreven we al dat bij Nehalem ook de HyperThreading technologie weer terug is van weggeweest. Dankzij HyperThreading - of Simultaneous Multi-threading (SMT) zoals de technologie officieel heet - kan iedere core tegelijkertijd instructies van twee programmathreads verwerken. Een quad-core Nehalem doet zich zodoende voor als zijnde een acht-core processor.

Met het verhaal van de verschillende execution units in het achterhoofd, wordt het nut van HyperThreading ineens een stuk duidelijker. We schreven immers dat een processor er alles aan moet doen om te allen tijde vier execution units bezig te houden. Wanneer een programma echter een hele rits instructies van hetzelfde type achter elkaar heeft staan, bijvoorbeeld een aantal floating point optel-instructies, kan slechts één execution unit worden bezig gehouden en staat een groot gedeelte van de core in feite in z'n neus te peuteren. Wanneer er dan ook instructies van een andere programmathread gebruikt kunnen worden, kunnen de executions units vaak wel optimaal gevuld worden en zal de processor zodoende efficiënter z'n werk doen.

Benchmarks zullen moeten gaan uitwijzen wat de resultaten zijn van HyperThreading bij Nehalem. Intel heeft enkele eigen benchmarks bekend gemaakt en die zijn veel belovend! Bij Cinebench 10 moet de CPU dankzij HyperThreading 16% beter presteren. Bij Pov-ray is de winst zelfs 29%. Het beste voordeel dat Intel wist te noemen, was de CPU-benchmark van 3DMark Vantage, die maar liefst een 34% hogere score geeft.

Het interessante aan de HyperThreading technologie is dat deze volgens Intel slechts ongeveer 5% extra die-size en daardoor ook ongeveer 5% extra stroomverbruik kost. Deze investering betaalt zich met dergelijke prestatiewinsten dubbel en dwars terug. 

Geheugenmanagement

Ook op het vlak van geheugenmanagement zijn er flinke verbeteringen. Een enigszins verborgen verbetering ten opzichte van Penryn die we kunnen zien in het blokschema van pagina 2 is een tweede TLB (Translation Lookaside Buffer). Zo'n TLB wordt gebruikt om eenvoudig een omrekening te kunnen maken tussen de geheugenadressen waar een programma mee werkt, naar daadwerkelijk fysieke adressen in het RAM-geheugen van de PC. Immers, een programma krijgt door het besturingssysteem gewoon een bepaalde hoeveelheid geheugen toegewezen, zeg 512 MB, waarbij het verder vanuit het programma niet duidelijk is (en ook niet nodig om te weten is) waar deze data zich daadwerkelijk bevindt op de geheugenmodules. De processor moet dus telkens als een programma een bepaald stuk geheugen opvraagt, berekenen op welk fysiek geheugenadres de data te vinden is. De TLB is, zoals de naam al aangeeft, een buffer waarin veelgebruikte geheugenadressen direct op te zoeken zijn.

De tweede laag TLB is nieuw in Nehalem. Deze is wat langzamer, maar daarentegen ook een stuk groter dan de primaire TLB. Wanneer een benodigd geheugenadres niet in de standaard TLB aanwezig is, is de kans bij Nehalem aanwezig de CPU deze wel snel in de tweede kan opvragen. Zodoende hoeft in minder gevallen een tijdrovende en daarmee prestaties beperkende berekening te worden uitgevoerd.

De tweede verbetering op het vlak van geheugenmanagement is wat complexer. Binnen x86 zijn er twee manieren om meerdere stukken data uit het geheugen op te vragen, aligned en non aligned. Aligned wil in dit geval kort door de bocht zeggen dat de gewenste data fysiek achter elkaar in het geheugen terug te vinden is. 

Wanneer de compiler 100% zeker weet dat dit bij een bepaalde operatie altijd het geval is, kan er gebruik gemaakt worden van aligned load-operaties. Wanneer die zekerheid er niet is, moet er worden gekozen voor de unaligned variant, die een stuk langer duurt en daarna implicaties heeft op de prestaties. Het frustrerende is, dat zelfs wanneer de data uiteindelijk toch in de juiste volgorde in het geheugen blijkt te staan, deze unaligned functies toch meer tijd in beslag nemen. Dát is bij Nehalem verleden tijd; het gebruik van unaligned instructie op data die toch aligned is, duurt exact even lang als wanneer er van een aligned instructie gebruik werd gemaakt. Deze potentiële bottleneck is dus helemaal weggenomen.

Een van de eigenschappen die ervoor zorgden dat de Core 2 processors veel sneller zijn dan hun voorloper, is de implementatie van hardware prefetchers. Deze voorspellen welke data de processor in de nabije toekomst nodig heeft en kopiëren die alvast van het relatief langzame RAM-geheugen naar het cache geheugen van de processor. In sommige gevallen wist alleen deze verbetering al zo'n 20% tot 30% prestatieverbetering te bewerkstelligen bij software. 

Een nadeel is echter dat de hardware prefetchers ook bij veel software falikant op hun bek gaan en telkens de verkeerde data naar de cache halen. In dergelijke gevallen hebben ze juist een negatieve invloed op de prestaties. Hoewel het om uitzonderingsgevallen gaat, is er aantal applicaties aan te wijzen, vooral op server vlak, waar de technologie roet in het eten gooit. Vandaar dat veel systeembeheerders bij hun servers de hardware prefetching juist uitzetten en ook overklokkers die bij sommige benchmarks de hoogste scores willen halen experimenteren daar vaak mee. Het uitzetten heeft echter weer als gevolg dat je ook de prestatiewinst mist bij software waar de techniek wél goed werkt.

Ook hier heeft Intel wat op bedacht. De vernieuwde prefetchers in de Nehalem architectuur controleren de hele tijd hoe goed de resultaten zijn die ze afleveren. Wanneer blijkt dat ze bij een bepaalde programmathread telkens de mist in gaan, wordt de werking  van de prefetchers op een lager pitje gezet. Ofwel; de prefetchers zijn zelfreguleren en zitten zich dus in feite uit wanneer ze slecht werk afleveren. Op die manier heb je wel altijd de kans op flinke prestatieverbeteringen, maar hoef je nooit bang te zijn dat de prestaties worden beperkt.

Caching

De cache architectuur van Nehalem is zoals al besproken ook compleet anders dan bij de Core architectuur van de bestaande Core 2 processors. Bij de bestaande CPU's heeft iedere core eigen L1 data- en instructiecache en daarnaast delen twee cores een stuk L2-cache. Bij Nehalem is ook die L2-cache voor iedere core afzonderlijk. Er is echter een derde, gedeelde cachelaag. De belangrijkste reden voor deze aanpassing is dat Nehalem native quadcore is; ofwel vier kernen in één chip. Als vier cores toegang zouden hebben tot de L2-cache, zou de toegangstijd daartoe in veel gevallen veel te lang worden. 

De Nehalem cores hebben elk 256 kB L2-cache die zeer snel te benaderen is. In de meeste gevallen bedraagt de toegangstijd zo'n 10 klokslagen. 

De L3-cache wordt gedeeld door alle cores. Deze is vanzelfsprekend langzamer dan de L2, maar nog altijd relatief snel. Wanneer een core data uit L3 wil halen, kost dat in de regel zo'n 35 a 36 klokslagen. De L3-cache is een 16-way ontwerp, wat betekent dat bij een quad-core processor iedere kern vier parallelle ingangen tot het cachegeheugen heeft.

De L3-cache is zogenaamde inclusive, want betekent dat alle data die in de L1 en L2 cache staat, ook verplicht in de L3-cache aanwezig moet zijn. Dat lijkt op het eerste gezicht onlogisch, aangezien je daardoor in feite onder de streep minder cache capaciteit hebt. Toch is dat juist erg slim, aangezien je op die manier direct een snoop filter kado krijgt.

De werking van een snoop filter is gelukkig niet lastig om te begrijpen. De basis zit hem in de functie van cache geheugen; dit doet immers dienst als een buffer voor het relatief veel tragere RAM-geheugen in de PC. Wanneer een core data wil verschrijven naar het geheugen, zal hij dit in eerste instantie naar zijn eigen L1- of L2-cachegeheugen doen. Daarna kan de core weer verder met nieuwe berekeningen, waarna de data op een later tijdstip daadwerkelijk naar het geheugen wordt overgebracht. Andersom werkt het ook; wanneer een core data uit het geheugen nodig heeft, wordt er getracht om deze vooraf al in het snelle cache te hebben staan.

Zodra een PC echter meerdere processors of meerdere cores heeft, ontstaat er een potentieel probleem. Stel dat core 1 een stuk data heeft verwerkt en dat wil wegschrijven naar geheugenruimte X. De nieuwe data staat dan op dat moment in z'n eigen cache, maar is nog niet doorgevoerd naar het RAM-geheugen. Wanneer de core juist op dat moment de geheugenruimte X uitleest, krijgt hij verouderde data binnen, want kan leiden tot een programma crash. Om dat probleem te verkomen zijn snoop filters bedacht. Zo'n snoop filter bekijkt wanneer er data uit het geheugen wordt opgevraagd, stiekem (snoopen dus in het Engels) of deze data toevallig in de cache van andere cores is aangepast. Zo ja, wordt data daar vandaan gehaald.

Aangezien de data van alle L1- en L2-caches van de afzonderlijke cores verplicht wordt gekopieerd naar de gedeelde L3-cache, hoeven de snoop filters nooit daadwerkelijk de cache van de andere cores in, waardoor deze niet vertraagd kunnen worden. Om de werking verder te verbeteren hebben alle cache-lijnen in de gedeelde L3-cache voor iedere core één extra bit aanwezig. Hiermee wordt aangegeven bij welke cores de betreffende data wel en niet in de L1- of L2-cache zit. Snoop filters weten op die manier direct of ze zich wel of geen zorgen moeten maken.

QuickPath

Een belangrijke eigenschap van de nieuwe Nehalem architectuur is natuurlijk de nieuwe processorbus. De QuickPath technologie is een snelle chip-naar-chip verbinding die veel weg heeft van AMD's HyperTransport. Het voordeel wordt vooral duidelijk bij systemen met twee of meer processors: de CPU's zijn dan niet meer allemaal afzonderlijk verbonden met de chipset, maar hebben juist direct verbindingen met elkaar, om op die manier zo snel mogelijk data uit te kunnen wisselen.

De eerste implementatie van QuickPath werkt met een bi-directionele 16-voudige datapaden tussen de verschillende chips. Met een snelheid van 6,4 Gigatransfers per seconde, resulteert dat in een doorvoersnelheid van 12,8 GByte/s in beide richtingen. Op bovenstaande afbeeldingen worden direct een aantal verschillen met de architectuur van AMD duidelijk. Zo hebben bij dual-CPU systemen beide processors een rechtstreekse verbinding met de chipset. Bij quad-CPU systemen kunnen processor een viertal QPI-links hebben, zodat er tussen elk paar van twee processors een directe verbinding bestaat. Bij AMD's Opterons is het aantal HyperTransport verbindingen per processor tot nu toe beperkt tot drie.

Geïntegreerde geheugencontroller

Een bijkomend aspect is de geïntegreerde geheugencontroller van Nehalem. Ook hier heeft Intel meer informatie over bekend gemaakt. We wisten al dat de eerste Nehalem chips die het levenslicht zullen zien, een triple-channel DDR3-geheugencontroller aan boord hebben. Doordat het geheugen rechtstreeks met de processor verbonden is, zijn de latencies veel lager dan bij huidige Intel platformen. Het hele concept van fully buffered DIMM's, zoals dat nu in Intel servers wordt toegepast, is overboord gegooid. Nehalem maakt voor desktop systemen gebruik van standaard DDR3-modules en voor servers van registered varianten.

In dual-CPU configuraties is er in feite nu een zes-kanaals geheugencontroller aanwezig. Intels huidige chipset voor quad-core Xeon-processors uit de Core-generatie is beperkt tot vier kanalen. Samen met de lagere latencies en hogere doorvoersnelheid van DDR3, heeft dit een gigantische prestatiewinst op geheugenvlak voor het nieuwe platform tot gevolg. Zo toonde Intel de resultaten van de veel gebruikte Stream geheugen benchmark. Een bestaande state-of-the-art server met twee Harpertown Xeon processors met 1600 MHz FSB en quad-channel FBDIMM DDR2-800 geheugen behaalt in de benchmark net geen 10 Gigabyte per seconde doorvoersnelheid. Een server op basis van twee Nehalem processors met elk triple-channel geheugen gaat met gemakk de 33 Gigabyte per seconde voorbij. Een stijging van 3,4x! Voor server applicaties die goed schalen met geheugen snelheid (zoals bijvoorbeeld database applicaties) kan de overstap naar Nehalem dus zeer interessant zijn. In feite geeft Intel inmiddels dus ook schoorvoetend toe dat de geheugenarchitectuur die AMD al sinds de Athlon 64 heeft gekozen, de enige juiste is.

Nu ook Intel processors een geïntegreerde geheugencontroller hebben, ontstaat er bij multi-processor systemen een zogenaamde NUMA (Non-uniform Memory Access) geheugen architectuur. Immer; software die fysiek op een bepaalde processor draait kan het best gebruik maken van het geheugen gedeelte dat direct aan de betreffende processor verbonden is, aangezien dat met de laagste toeganstijd benaderd kan worden. Om een andere geheugenpartitie te benaderen, moet er immers via een andere CPU gecommuniceerd te worden. Het besturingssysteem moet hier rekening mee houden en het geheugen zo slim mogelijk indelen.

Hier kan Intel echter profiteren van de wet van de remmende voorsprong. AMD heeft met haar Opterons inmiddels immers al enkele jaren een NUMA geheugen architectuur, met als resultaat dat alle besturingssystemen (Windows, Linux, etc.) er al volledig voor zijn geoptmaliseerd. Intel profiteert daar nu direct van mee.

Interessant is overigens dat zelfs wanneer er gebruik gemaakt wordt van geheugen dat aan een andere processor hangt, de totale wachttijd nog altijd lager is dan bij het huidige Intel platform, waarbij de geheugencontroller in de chipset zit. Dat is te zien in onderstaande grafiek. De meest linkse, oranje balk is de gemiddelde lantency van een bestaand Harpertown platform, genormaliseerd naar 1. De latency als gevolg van de geïntegreerde geheugencontroller is volgens deze Intel benchmarks zo'n 40% sneller. Wanneer er van geheugen van de tweede CPU gebruik gemaakt wordt, gaat dit nog altijd een fractie sneller dan vroeger.

Virtualisatie

Ook op het vlak van ondersteuning voor virtualisatie zijn er onder de motorkap flinke verbeteringen. Intel heeft opnieuw getracht om de overhead van het gevirtualiseerd draaien van besturingssystemen zo veel mogelijk terug te dringen. Hiervoor heeft men een aantal interessante vindingen uitgedokterd. Deze slaan voornamelijk weer op het eerder in dit artikel uitgelegde verhaal van de Translation Lookaside Buffers (TLB's).

In een gevirtualiseerde omgeving heeft iedere virtual machine immers zijn eigen set TLB informatie. Dat betekent in de praktijk dat wanneer er wordt omgeschakeld van de ene VM naar de andere, dat de hele inhoud van de TLB moet worden weggeschreven naar RAM-geheugen en daarna de TLB informatie van de andere VM moet worden ingeladen. Deze acties kosten heel wat klokslagen en zijn daarmee een groot gedeelte van de overhead bij het gevirtualiseerd draaien van besturingssystemen.

Bij de Nehalem architectuur krijgt iedere virtual machine een zogenaamd virtual processor ID toegewezen. Alle combinaties in de TLB worden vervolgens getagd met dat VPID. Op die manier weet de processor exact welk gedeelte van de TLB bij welke virtual machine hoort en hoeft de TLB nooit meer te worden weggeschreven of opnieuw ingelezen.

Hypervisor software moet hier overigens wel voor geschikt gemaakt worden, maar Intel heeft inmiddels aangekondigd dat ondermeer VMware deze processorextensies in een toekomstige versie van de ESX HyperVisor zullen ondersteunen. Ook Xen komt spoedig met een geschikte versie.

 

Volgens Intel is de duur van het overschakelen tussen twee VM's bij de afgelopen processorgeneraties dankzij dergelijke verbeteringen flink gedaald. Penryn schijnt al zo'n 40% minder overhead te hebben dan de eerste processors met de Core architectuur. Bij Nehalem heeft Intel de overhead opnieuw met zo'n 33% ingeperkt.

Nieuwe instructies

De nieuw instructies van de Nehalem architectuur hebben we in onze oorspronkelijke preview al uitgebreid besproken. Om het verhaal te complementeren, laten we ze graag nog eens de revue passeren. In totaal zijn er zeven nieuwe instructies, die allen vallen onder de naam SSE 4.2. Vijf van de zeven instructies zijn speciaal bedacht om het verwerken van XML te versnellen. Zo zijn er instructies die het zoeken binnen strings flink kunnen versnellen. Voor veel internet servers kan dat men juiste software voor een aardige winst zorgen. 

De zesde instructie is om het aantal enen in een register te tellen. Dit schijnt handig te zijn bij zaken als patroonherkenning. De laatste nieuwe instructie kan in één klap de CRC32 hash van een stuk data bepalen. Deze instructie is ondermeer toegevoegd om de drivers van iSCSI hardware flink te versnellen.

Power controller

Naast betere prestaties, moet Nehalem bovenal ook een betere performance per Watt verhouding brengen. Om dat te bewerkstelligen, heeft Intel een aantal verregaande nieuwe mogelijkheden op het vlak van stroombesparing ingevoerd. De belangrijkste is de implementatie van een speciale power control unit in de processor. Deze meet continu ondermeer de temperatuur en het stroomverbruik van alle cores en overlegt op basis van al deze informatie met het besturingssysteem op welke snelheden de verschillende cores moeten draaien. Daarnaast stelt de power control unit ook op ieder moment in overleg met de VRM's op het moederbord het ideale voltage in. De komst van zo'n power control unit is uniek; tot nu toe gebeurde het verwerken van temperatuur- en stroomgegevens nog softwarematig. In feite berekenden de cores dus zelf hun eigen werkwijze, wat de effciëntie niet ten goede kwam.

De gegevens van de power control unit kunnen als het goed is door software worden uitgelezen. In de toekomst kunnen we dus software verwachten die exact weet te vertellen hoe warm alle cores zijn, hoeveel stroom ze verbruiken, en zo verder. 

Een andere belangrijke vernieuwing is de mogelijk om cores afzonderlijk geheel uit te schakelen. Dat kan bij bestaande Core 2 processors ook al, maar vanwege de kleine transistors houd je dan nog altijd aardig wat stroomverbruik vanwege lekstroom. In Nehalem wordt een nieuw soort schakelaars gebruikt, waardoor niet gebruikte cores geheel van de stroomtoevoer worden afgesloten. Op dit manier is er ook geen lekstroom meer en is het verbruik van uitgeschakelde cores in feite verwaarloosbaar. Op die manier is volgens Intel het idle stroomverbruik van Nehalem duidelijk lager dan dat van Penryn.

Turbo modus

Het laatste belangrijkste aspect is de gisteren ook al in de nieuws sectie besprokent Turbo Modus die de nieuwe architectuur krijgt. De besproken power controller zorgt ervoor, dat cores die niet gebruikt worden automatisch uitgeschakeld worden en op dat moment gaan de overgebleven cores automatisch op een hogere klokfrequentie werken. Op die manier zal Nehalem ook bij single-threaded software voor duidelijk betere prestaties dan de huidige generaties CPU's zorgen. Als drie van de vier cores idle zijn, kan de vierde op een aardige hogere snelheid werken.

Een van de Hardware.Info lezers reageerde al direct met de melding dat dit oud nieuws was en dat dit al lang bekend was. Een begrijpelijke misvatting; de turbo modus van Nehalem is daadwerkelijk gisteren voor het eerst aangekondigd, maar nieuw is het concept zeker niet. De mobiele varianten van Penryn hebben immers een vergelijkbare technologie aan boord.

Toch gaat men bij Nehalem nóg een stapje verder. Wanneer cores wel in gebruik zijn, maar de betreffende load het stroomverbruik niet tot de maximum waarde laat oplopen, kan de klokfrequentie ook worden verhoogd. In feite kun je dus zeggen dat Nehalem zichzelf, waar mogelijk, overklokt.

Conclusie

Er was al veel bekend over Nehalem, maar Intel heeft tijdens haar Developer Forum nog een flink aantal missende puzzelstukjes bekend gemaakt. Op basis van de informatie die we nu hebben, mogen we wel concluderen dat Nehalem een zeer vernuftig ontwerp is. Niemand kan ontkennen dat veel van de nieuwigheden op z'n minst zijn geïnspireerd door de architectuur van AMD's Athlon 64. Dat kunnen we echter alleen maar positief opvatten: bij AMD zagen we bij de overstap van de Athlon naar de Athlon 64 een aardige prestatiewinst dankzij ondermeer de geïntegreerde geheugencontroller. Bij Intel zullen we die winst nu bovenop de toch al uitstekende prestaties van de Core 2 processors gaan zien. Tel daar de vele grote en kleine architecturele verbeteringen bij op en we mogen Nehalem op z'n minst veelbelovend noemen.

De komende dagen zullen we vermoedelijk de gelegenheid gaan krijgen om enkele benchmarks op Nehalem systemen los te laten. Houd Hardware.Info dus ook de rest van de week in de gaten voor meer Intel Developer Forum nieuws!

 

0
*