En dramatisk händelseutveckling är det bästa sättet att beskriva vad vi kommer att se om några veckor. Men låt oss först tala om den nuvarande situationen. Som vi påpekade i
, AMD senaste quadcore Opteron var en mycket positiv överraskning. Visst, du kan visa några serverriktmärken där Intel-processorn vinner som Black Scholes eller något exotiskt HPC-riktmärke men serverapplikationerna som verkligen gör skillnaden som webbservrar, databasservrar
. Allt beror förstås på vilken typ av ansökan som är viktig för dig. Men låt oss titta på hela bilden:
är det sista beviset på att AMD:s senaste överlag är den bästa server-CPUn vid denna tidpunkt.
- Simultaneous Hyperthreading erbjuder prestandahöjningar som IPC-förbättringar inte kan leverera (upp till 45%!).
- Minnesfördröjning. Nehalems minneslatens är upp till 40 % lägre
- Minnesbandbredd: 3 kanaler är komplett överdrift för stationära appar, men det gör underverk för många HPC och i mindre grad serverapplikationer.
- en riktigt aggressiv heltalsmotor
Nehalem kommer att använda något dyrare DDR-3 DIMM, som knappast ger några riktiga prestandahöjningar (jämfört med DDR-2). Så att flytta till DDR-3 kommer inte att hjälpa AMD mycket.
Istanbul?
Detaljerna om det sexkärniga Istanbul är fortfarande skissartade. Men den dubbla sockeln Xeon “Westmere” kommer också att få sex kärnor och kommer att dyka upp i samma tidsram som AMD:s hexacore. Bara om AMD lade till SMT i hemlighet till Istanbul, kommer de att kunna vända utvecklingen. Med tanke på att detta skulle vara det första för AMD, är det mycket osannolikt att SMT kom till Istanbul.
En buckla i Nehalems rustning?
Har AMD en chans på servermarknaden 2009 (och möjligen 2010)? Jag måste säga att det inte var lätt att hitta en svaghet i Nehalems arkitektur. Utmaningen gjorde det väldigt attraktivt att söka ändå :-). Så vad som följer är en stor “OM-iF”-historia och du bör ta den med en stor nypa salt … som du alltid borde göra med framåtblickande artiklar.
Det finns en marknad där AMD verkligen har varit ledande och det är virtualisering tack vare IMC och stödet för segment (fyra privilegienivåer) i AMD64 Instruction Set Architecture. AMD:s prestanda att köra VMware ESX i det “gamla goda” ESX binära översättningsläget (mjukvaruvirtualisering) var bättre än att köra en Intel på den senaste hårdvaruvirtualiseringshypervisorn. VMware använder bara hårdvaruvirtualisering på en AMD-server om NPT (eller RVI eller HAP) är närvarande. Däremot saktade hårdvaruvirtualisering Xeons 2005 och 2006 ner lite men var absolut nödvändigt för att köra 64-bitars gäster på en hypervisor ovanpå en Xeon-server.
Nehalem kommer ikapp med EPT och VPID (kolla här), och även om det var väl implementerat, saknas en sak: TLB är ganska liten. jag har varit påpekar detta för ungefär ett år sedan: medan TLB fick AMD mycket dålig press, kommer det förmodligen att vara den enda sak som håller AMD något i Intels slipstream. Låt mig göra det tydligare:
| CPU |
L1 TLB-data |
L1 TLB Instr |
L2 TLB |
| AMD Shanghai/ Opteron 238x eller 838x |
48 (4 kB) 48 (stor) |
48 (4 kB) 48 (stor) |
512 (4 kB) 128 (stor) |
| Intel Penryn / Xeon 54xx |
16 (4 kB) 16 (stor) |
128(4 kB) 8 (stor) |
256 (4 kB) 32 (stor) |
| Intel Nehalem / Xeon 55xx |
64 (4KB) 32 (stor) |
128 (4 kB) 14 (stor) |
512 (4 kB) 0 (stor) |
Observera att om du använder stora sidor, har Nehalem TLB få poster. Så låt oss nu göra ett tankeexperiment. För närvarande använder de flesta virtualiseringsriktmärken som VMmark (VMware) och VConsolidate (Intel) relativt små virtuella datorer. VM:er är till exempel en liten Apache-webbserver och Mysql-server som får mellan 512 MB och 2 GB RAM. Som ett resultat av detta körs de flesta med stora sidor avstängda (Sidstorlek = 4 KB). Dessa riktmärken påminner mycket om den dagliga praxisen i ett företag som använder IT mest för “infrastruktursyften” som att autentisera sina anställda och ge dem tillgång till e-post, ftp, filserver, utskriftsservering och webbsurfning.
Helt annorlunda blir det när man är en IT-firma som erbjuder sina tjänster till ett relativt stort antal kunder på internet. Du behöver en stor databas med många förmodligen ganska tunga webbportaler som erbjuder en bra interaktiv upplevelse.
Så du kommer inte att konsolidera något som 84 (14 brickor x 6 virtuella datorer) små virtuella datorer på en fysisk maskin, utan snarare 5 till 10 “feta” virtuella datorer. Med feta virtuella datorer menar jag virtuella datorer som får 4 GB och mer RAM, 2 till 4 vCPU:er, kör ett 64-bitars gäst-OS och så vidare.
Dessa applikationer öppnar också massor av anslutningar, som de måste förstöra och återskapa efter en tid. Med andra ord, mycket minnesaktivitet pågår.
EPT och NPT kan erbjuda mellan 10 och 35 % bättre prestanda när mycket minneshantering pågår. Jämfört med tekniken för skuggsidtabeller orsakar inte varje ändring i sidtabellerna en fälla och tillhörande overhead (vilket kan vara 1000-tals cykler). Så man kan säga att det är mycket smidigare att gå till TLB på din CPU. Men om TLB misslyckas med att leverera är sidpromenaden för hårdvara mycket kostsam.
På jakt efter den riktiga sidtabellen
En sidvandring för hårdvara består av att söka i flera tabeller som gör att CPU:n kan hitta den verkliga fysiska adressen eftersom den körande programvaran alltid tillhandahåller en virtuell adress. Med ett normalt operativsystem har operativsystemet ställt in CR3-registret så att det innehåller en fysisk adress där den första tabellen finns. Den första tabellen konverterar den första delen av den virtuella adressen till en fysisk, en pekare mot den fysiska adressen där nästa tabell ligger. Med stora sidor tar det cirka 3 steg att översätta den virtuella adressen till den fysiska.
Med EPT/NPT ger gästoperativsystemet en (CR3) adress som faktiskt är virtuell och som måste omvandlas till en riktig fysisk adress. Alla gäst OS-tabeller innehåller pekare till virtuella adresser. Så varje tabell ger dig en virtuell adress till det andra bordet. Men nästa tabell finns inte på den här virtuella adressen, så vi måste gå ut och söka efter den riktiga adressen. Så istället för 3 åtkomster till minnet, vi behöver 3×3-åtkomster. Om detta händer för många gånger kommer EPT faktiskt att minska prestandan istället för att förbättra den!
Det är bra att använda stora sidor med stor databas. Kom nu ihåg att vi går mot ett datacenter där nästan allt är virtualiserat, inklusive databaser. I så fall kan Nehalems TLB bara se till att cirka 32 x 2 MB eller endast 64 MB data och 28 MB kod täcks av TLB. Som ett resultat kommer det att hända många relativt tunga sidvandringar i hårdvaran. Lyckligtvis cachar Intel de verkliga fysiska sidtabellerna i L3-cachen, så det borde inte vara för smärtsamt.
Den senaste quadcore Opteron har en mycket mer potent TLB. Eftersom instruktioner tar mycket mindre utrymme än data, är det säkert att säga att data TLB kan täcka upp 176 (48 + 128) gånger 2 MB eller 352 MB data. Med tanke på att virtualiserade maskiner lätt har mellan 32 och 128 GB och är mycket bättre utnyttjade (60-80 % CPU-belastning) är det tydligt att AMD-chippet har en fördel där. Hur stor skillnad kan detta göra? Vi måste mäta det, men baserat på vår profilering och tidiga benchmarking tror vi att “en överfull TLB” kan minska virtualiserad prestanda med så mycket 15 %. För att vara ärlig: det är för tidigt att säga, men vi är ganska säkra på att det inte är jordnötter i vissa viktiga tillämpningar.
Så vad säger vi? Tja, det är möjligt att Opteron kanske kan göra lite “skadekontroll” jämfört med Nehalem när vi provar ett benchmark med stora och feta virtuella datorer (som vi har gjort här). Men det finns många “OM”:n. För det första måste AMD också cache sidtabellerna i cacharna. Om de av någon anledning håller sidtabellerna borta från cachen, kommer fördelen förmodligen delvis att förnekas. För det andra, om applikationerna som körs på den fysiska maskinen kräver mycket bandbredd, kan det faktum att Nehalem-plattformen har upp till 70 % mer bandbredd också förstöra fördelen.
Det sista AMD Stronghold?
Så borde Intel oroa sig för detta? Med största sannolikhet inte. För enkelhetens skull, låt oss anta att båda kärnorna – Shanghai och Nehalem – erbjuder lika stor kraft. Det gör de mer eller mindre när det kommer till ren rå FP-kraft, men SpecInt gör klart att Nehalem är snabbare i heltalsbelastningar.
Men låt oss glömma det, eftersom de flesta serverapplikationer inte kan använda all den superskalära kraften ändå. AMD-chippet är fortfarande missgynnat av att det inte har SMT. Med tanke på att de flesta serverappar har gott om trådar och att virtualisering gör det enklare att ladda varje logisk CPU upp till 80 %, vilket fortfarande är svårt att stänga. För det andra, många av dessa applikationer passar inte helt i cachen, så det faktum att AMD:s minneslatens är upp till 40% högre hjälper inte heller. För det tredje kan alla topp Xeoner (2,66 GHz och högre) lägga till 2 extra speedbins även om alla 4 kärnor är upptagna (som det var fallet i SAP). Det ska bli intressant att se hur mycket kraft detta kostar, och om Turbo-läge är möjligt med en 80% laddad virtualiserad maskin.
I ett nötskal: förvänta dig att Nehalem med sin rikliga bandbredd och EPT kommer att klara sig mycket bra i VMmark. Vi tror dock att AMD kan stanna i slipströmmen av Intels flaggskepp i vissa virtualiseringsinställningar. Det är möjligt att AMD räknar med en ännu bättre optimerad minneskontroller i Istanbul, men det kommer att bli tufft.
Återvänd till Linpack
De riktmärken där AMD kommer att kunna hålla sig nära bör inte ha någon användning för stora mängder minnesbandbredd, SMT eller Turbo-läge. Känna free för att utbilda oss, men hittills har vi bara hittat ett riktmärke som svarar på denna profil: Linpack. Linpack uppnår de högsta IPC-hastigheterna av förmodligen nästan alla programvaror. Det betyder att Nehalem Xeon kommer att förbruka toppeffekt och inte kommer att kunna använda turboläget. Linpack (med MKL eller ACML) är också så noggrant optimerad att den körs nästan helt i cachen, och SMT eller hypertrådning stör bara de noggrant placerade kodraderna. Med tanke på att en 2,7 GHz Shanghai-processor med registrerat RAM-minne bara var en liten bit långsammare än en Nehalem-processor med icke-registrerat RAM-minne, kan du förvänta dig att se båda processorerna mycket nära i detta riktmärke.
Utsikter till 2009
AMD quadcore är nu servern CPU att få, men det kommer inte att förbli så länge. Tills AMD kommer med SMT eller annan form av multi-threading och en snabbare minneskontroller, kommer Intels senaste plattform och CPU att tvinga AMD att göra quadcore-opteronen väldigt billig. Vi förväntar oss att AMD quadcore endast kommer att vara konkurrenskraftig i Linpack och vissa virtualiseringsscenarier.
Och om inte Istanbul har en mycket trevlig överraskning för oss, kommer det inte att förändras snart. Håller med, till våra trogna läsare, detta kommer inte som en överraskning…
