AMD försvarar designval för Epyc-processorer med fyra kretsar

Allt AMD skriver där är absolut sant, men alla mynt har två sidor och (av uppenbara skäl) visar detta bara framsidan med en MCM-design.

Fördelarna med en monolitisk kärna är

• väsentligt lägre "worst-case" latens mellan kärnor, skiljer i praktiken 4-5 heltalsfaktorer

• väsentligt högre bandbredd mellan kärnor, skiljer nästan en tiopotens

• systemet blir som helhet mer homogent vilket gör det lättare att förutsäga kapacitet och även lättare att optimera

Ur alla praktiska aspekter sett från OSet och applikationsprogrammerarnas synvinkel är en Epyc CPU identiskt med ett quad-socket system med monolitiska kärnor med åtta kärnor var.

ServeTheHome har gjort en del tester som precis visar detta
Sett till latens/bandbredd mellan CPU-dies i Epyc är den i det närmaste identisk med latens/bandbredd Skylake SP har mellan sockets

Bandbredd är något som rent teoretiskt kan fixas, bara dra fler ledningar! I något läge blir det opraktiskt av flera orsaker, bl.a. kostnad. Men det finns i alla fall en teoretisk lösning där.

Latens är en direkt följd av fysikens lagar. Bandbredd mellan CPU-sockets har ökat rätt mycket sedan Nehalem, latensen har ändras klart mindre än en faktor två på samma tidsperiod. PcPerspective har lite tester kring detta och konstaterar att ThreadRipper har ungefär samma latens mellan sina CPU-dies som deras Ivy Bridge baserade dual-socket Xeon E5 har mellan sockets (Skylake SP har kanske 10-20 % lägre latens).

MCM kommer absolut bli vanligare, Moores lag kommer allt närmare sin död. Där MCM fungerar är det en mer kostnadseffektiv lösning. Men det är en smalare lösning än en monolitisk design då MCM kräver applikationer som är optimerade för NUMA, där relativt hög latens och låg bandbredd mellan kärnor inte spelar något stor roll.

AMD har en riktigt bra lösning på detta med MCM "Infinity fabric"!
Intel har fortfarande inte fattat vad som hänt, så man smutskastar konkurrenten!
Nvidia har fattat att detta är framtiden och gått ut med att dom håller på att ta fram en MCM teknik.

Detta är defenitivt en kostnadseffektiv teknik, samtidigt som prestandan verkar skala väldigt bra mellan moduler, så AMD ska ha cred för det, de ligger lite för de andra med denna teknik just nu. De andra lär nog jobba på med att utveckla liknande, får se hur länge det tar bara.

ServerTheHome har en del tester som visar att Epyc är väldigt konkurrenskraftig mot Skylake SP i vissa lägen medan den faller efter rejält i andra, vilket är precis vad man kan förvänta sig. Vissa saker skalar helt enkelt inte bra med fler CPU-sockets.

För att ta ett exempel: relationsdatabaser pratar om ACID, för att upprätthålla "C" i detta gör high-end databaserna en hel del tricks på NUMA-system.

Så länge man bara läser blir det på flera sätt en fördel att ha flera oberoende CPU-delar med egen access mot RAM då kapaciteten skalar väldigt fint med ökad beräknings- och RAM-bandbreddskapacitet.

Problemet uppstår när man ska skriva, att då upprätthålla "C" skalar negativt då de optimeringar man gör ökar latensen för att garantera att alla ser en enhetligt bild av allt data.

Ett exempel när bandbredd mellan CPU-kärnor är kritiskt är HPC-laster där man beskriver sitt problem i form av matriser (typ de flest fall). Detta kan skalas både över CPU-kärnor och över SIMD (AVX/SSE), även på Intels monolitiska kretsar slår man ofta in i bandbreddsproblem här (GPUer är en form av SIMD CPUer, de har brutal bandbredd av en anledning...).

Både Cavium och Qualcomm jobbar på 64-bitars "big-core" ARM CPUer för servers. Båda tänker bl.a. sikt in sig på HPC-marknaden så båda har monolitiska CPUer. Qualcomm presterade faktiskt sin design på samma konferens det denna artikel är taget från. 48 ARM kärnor som på mikroarkitekturnivå påminner en hel del om Zen kan bli en svettig konkurrent för x86-lägret!

AMD har ett whitepaper om Epyc, där konstaterar man bl.a. att ~30 % av alla servers endast använder en CPU-socket. Personligen misstänker jag att en inte allt för ovanlig orsak till detta är att kunden i det läget vet med sig att man har en last som inte fungerar väl över flera NUMA-zoner (på det stora hela är det rätt få applikationer ens på serversidan som är NUMA-optimerade).

Om det var mängd I/O som var flaskhalsen skulle man ju i stället välja två billigare CPUer då det dubblar antal PCIe-linor + det dubblerar total RAM-bandbredd och RAM-kapacitet.

Försvarar vadå? Att dom utifrån sin ekonomiska situation tar fram en kostnadseffektiv lösning, eller?

Finns inget att försvara. Det är ett solklart val i detta fallet.
Utöver att det är mycket billigare att tillverka, så även om de fick till någorlunda yields på en 32-kärnorsklump. Vilka frekvenser hade den klarat, och till vilken värmeutveckling?

Utöver att kostnaderna hålls nere med MCM-lösningen så tror jag också att de med den kan erbjuda markant högre frekvens till lägre effekt. Så bortsett från laster där latenser mellan alla kärnor är det viktigaste så tror jag detta ger mer prestanda till kunden.

Hade man begärt allt i en enda krets så hade vi nog inte fått se EPYC alls. Infinity Fabric kommer nog spela en roll i AMDs förmåga att hålla sig konkurrenskraftiga framöver. Inte minst i lösningar tillsammans med GPU.

Nu har du fått om det om bakfoten. Ryzen, Threadripper och EPYC är uppbyggt av samma krets, nämligen Zeppelin kretsen och skillnaden är hur många det finns i respektive grupp: Ryzen har 1 krets, Threadripper 2 och EPYC 4 kretsar.

Alla dessa produkter är byggda av samma krets, vilket framgår i artikeln:

Det som jag ifrågasatte var att Sweclockers hade skrivit att kretsytan för denna krets, Zeppelin, var 192 mm2 när denna är 213 mm2 enligt artikeln.

Blanda ihop inte detta med storleken på CPU-paketet (eng: CPU package) som är själva storleken på CPUn, dvs det du ser när du köper en CPU och monterar in det i moderkortet, en krets är bara en del av CPU-paketet.

Här vet jag att Threadripper och EPYC är större än Ryzen men dessa består i sin tur av samma krets som finns i Ryzen men skillnaden är att dessa har fler av dem som EPYC med sina 4 kretsar i bilden nedan.