Anslut till Senaste Tekniska Nyheter, Bloggar, Recensioner

Förhandsgranskade IBM just The Future of Caches?

På Hot Chips förra veckan tillkännagav IBM sin nya stordator Z-processor. Det är en stor intressant del av kit som jag vill göra en bredare del på någon gång, men det fanns en funktion i den kärndesignen som jag vill plocka ut och fokusera på specifikt. IBM Z är känt för att ha stora L3-cacher, uppbackade med ett separat globalt L4-cache-chip som fungerar som en cache mellan flera socklar av processorer – med det nya Telum-chippet har IBM gjort bort det – det finns ingen L4, men intressant nog, det finns ingen L3. Vad de har gjort istället kan vara en indikation på framtiden för on-chip-cachedesign.

Cacher: A Brief Primer

Varje modern processor har flera nivåer av cache associerad med den. Dessa är åtskilda av kapacitet, latens och kraft – den snabbaste cachen närmast exekveringsportarna tenderar att vara liten, och sedan längre ut har vi större cacher som är något långsammare, och sedan kanske ytterligare en cache innan vi träffar huvudminnet. Cacher finns eftersom CPU-kärnan vill ha data NU, och om allt hölls i DRAM skulle det ta 300+ cykler varje gång att hämta data.

En modern CPU-kärna kommer att förutsäga vilken data den behöver i förväg, ta den från DRAM till sina cacher, och sedan kan kärnan ta tag i den mycket snabbare när den behöver den. När cacheraden väl har använts “avhyss” den ofta från den närmaste nivåcachen (L1) till nästa nivå upp (L2), eller om den L2-cachen är full kommer den äldsta cacheraden i L2 att vräkas till en L3-cache för att göra plats. Det betyder att om den datalinjen någonsin behövs igen, är den inte så långt borta.


Ett exempel på L1, L2 och en delad L3 på AMDs First Gen Zen-processorer

Det finns också omfattningen av privata och delade cachar. En modern processordesign har flera kärnor, och inuti dessa kärnor kommer det att finnas minst en privat cache (L1) som bara den kärnan har tillgång till. Utöver det kan en cache antingen vara en privat cache som fortfarande är lokal till kärnan, eller en delad cache, som vilken kärna som helst kan använda. En Intel Coffee Lake-processor har till exempel åtta kärnor, och varje kärna har en 256 KB privat L2-cache, men chipbrett finns det en 16 MB delad L3 mellan alla åtta kärnorna. Detta innebär att om en enskild kärna vill, kan den fortsätta att vräka ut data från sin mindre L2 till den stora L3 och ha en pool av resurser om denna data vill återanvändas. Inte bara detta, utan om en andra kärna också behöver en del av den datan, kan de hitta den i den delade L3-cachen utan att behöva skriva ut den till huvudminnet och ta tag i den där. För att komplicera saken, delas en “delad” cache inte nödvändigtvis mellan alla kärnor, den kanske bara delas mellan några få.

Slutresultatet är att cacher hjälper till att minska tiden till exekvering och tar in mer data från huvudminnet om det behövs eller när det behövs.

Avvägningar

Med det i åtanke kan du fråga dig varför vi inte ser 1 GB L1- eller L2-cacher på en processor. Det är en helt berättigad fråga. Det finns ett antal element på spel här, som involverar tärningsarea, nytta och latens.

Dörrområdet är lätt att ta itu med först – i slutändan kanske det bara finns ett definierat utrymme för varje cachestruktur. När du designar en kärna i kisel kan det finnas ett bästa sätt att lägga ut komponenterna i kärnan för att få den snabbaste kritiska vägen. Men cachen, särskilt L1-cachen, måste vara nära där data behövs. Att designa den layouten med en 4 KB L1-cache i åtanke kommer att bli väldigt annorlunda om du istället vill ha en stor 128 KB L1-cache. Så det finns en avvägning där – bortom L1, är L2-cachen ibland en storkonsument av matrisutrymme, och även om den (vanligtvis) inte är lika begränsad av resten av kärndesignen, måste den fortfarande balanseras med vad behövs på chippet. Varje stor delad cache, oavsett om den slutar som en nivå 2-cache eller en nivå 3-cache, kan ofta vara den största delen av chipet, beroende på vilken processnod som används. Ibland fokuserar vi bara på densiteten hos logiktransistorerna i kärnan, men med superstora cacher kanske cache-densiteten är viktigare i vilken processnod som slutar användas.

Utility är också en nyckelfaktor – vi talar mest om processorer för allmänna ändamål här på AnandTech, särskilt de som är byggda på x86 för PC och servrar, eller Arm för smartphones och servrar, men det finns massor av dedikerade designs där ute vars roll är för en specifik arbetsbelastning eller uppgift. Om allt en processorkärna behöver göra är att bearbeta data, till exempel en kamera AI-motor, så är den arbetsbelastningen ett väldefinierat problem. Det betyder att arbetsbelastningen kan modelleras och storleken på cacharna kan optimeras för att ge bästa prestanda/kraft. Om syftet med cachen är att föra data nära kärnan, så kallas det en cachemiss när som helst som data inte är klar i cachen – målet med varje CPU-design är att minimera cachemissar i utbyte mot prestanda eller kraft, och så med en väldefinierad arbetsbelastning kan kärnan byggas kring de cacher som behövs för ett optimalt förhållande mellan prestanda och cachemiss.

Latency är också en stor faktor för hur stora cacher är designade. Ju mer cache du har, desto längre tid tar det att komma åt – inte bara på grund av den fysiska storleken (och avståndet bort från kärnan), utan för att det finns mer av det att söka igenom. Till exempel kan små moderna L1-cacher nås på så lite som tre cykler, medan stora moderna L1-cacher kan vara fem cykler med latens. En liten L2-cache kan vara så låg som åtta cykler, medan en stor L2-cache kan vara 19 cykler. Det finns mycket mer som går till cachedesign än att bara större är lika med långsammare, och alla de stora CPU-designföretagen kommer mödosamt att arbeta för att raka ner dessa cykler så mycket som möjligt, för ofta erbjuder en latensbesparing i en L1-cache eller en L2-cache goda prestationsvinster. Men i slutändan om du blir större måste du ta hänsyn till det faktum att latensen ofta blir större, men din cachemissfrekvens blir lägre. Detta kommer tillbaka till föregående stycke där vi pratar om definierade arbetsbelastningar. Vi ser företag som AMD, Intel, Arm och andra som gör omfattande arbetsbelastningsanalyser med sina stora kunder för att se vad som fungerar bäst och hur deras kärndesign ska utvecklas.

Så vad har IBM gjort som är så revolutionerande?

I det första stycket nämnde jag att IBM Z är deras stora stordatorprodukt – det här är branschens stora järn. Den är byggd bättre än din regeringsgodkända kärnkraftsbunker. Dessa system stöder de kritiska delarna av samhället, såsom infrastruktur och bankverksamhet. Driftstopp för dessa system mäts i millisekunder per år, och de har fail-safes och fail overs i överflöd – med en finansiell transaktion, när den görs, måste den vara ansluten till alla rätt databaser utan att misslyckas, eller till och med i händelse av fysiskt misslyckande längs kedjan.

Det är här IBM Z kommer in. Det är otroligt nisch, men har otroligt fantastisk design.

I den tidigare generationens z15-produkt fanns det inget koncept med en 1 CPU = 1 systemprodukt. Basenheten för IBM Z var ett system med fem processorer, med två olika typer av processorer. Fyra beräkningsprocessorer (CP) rymde vardera 12 kärnor och 256 MB delad L3-cache i 696 mm2 byggd på 14nm som körs på 5,2 GHz. Dessa fyra processorer delade upp sig i två par, men båda paren var också kopplade till en System Controller (SC), även den 696mm2 och på 14nm, men denna systemkontroller höll 960 MB delad L4-cache, för data mellan alla fyra processorerna.

Observera att detta system inte hade ett “globalt” DRAM, och varje Compute Processor hade sitt eget DDR-stödda motsvarande minne. IBM skulle sedan kombinera denna “låda” med fem processorer, med fyra andra för ett enda system. Det betyder att ett enda IBM z15-system var 25 x 696 mm2 kisel, 20 x 256 MB L3-cache mellan dem, men också 5 x 960 MB L4-cache, anslutet i en allt-till-alla-topologi.

IBM z15 är ett odjur. Men nästa generations IBM Z, kallad IBM Telum snarare än IBM z16, tar ett annat förhållningssätt till all den där cachen.

IBM, berätta vad de ska göra med cachen

Det nya systemet gör bort den separata systemkontrollern med L4-cachen. Istället har vi vad som ser ut som en vanlig processor med åtta kärnor. Byggd på Samsung 7nm och på 530 mm2, paketerar IBM två processorer till en och lägger sedan fyra paket (åtta processorer, 64 kärnor) i en enda enhet. Fyra enheter utgör ett system, för totalt 32 processorer / 256 kärnor.

På ett enda chip har vi åtta kärnor. Varje kärna har 32 MB privat L2-cache, som har en 19-cyklers åtkomstlatens. Detta är en lång latens för en L2-cache, men den är också 64 gånger större än Zen 3:s L2-cache, som är en 12-cyklers latens.

Om man tittar på chipdesignen är allt utrymme i mitten L2-cache. Det finns ingen L3-cache. Ingen fysisk delad L3 för alla kärnor att komma åt. Utan ett centraliserat cache-chip som med z15 skulle detta innebära att för att kod som har en viss mängd delad data ska fungera så skulle den behöva en tur och retur ut till huvudminnet, vilket är långsamt. Men IBM har tänkt på detta.

Konceptet är att L2-cachen inte bara är en L2-cache. I själva verket är varje L2-cache verkligen en privat cache för varje kärna, och 32 MB är otroligt stort. Men när det är dags för en cache-linje att vräkas från L2, antingen avsiktligt av processorn eller på grund av att den behöver göra plats, snarare än att bara försvinna försöker den hitta utrymme någon annanstans på chippet. Om den hittar ett mellanslag i en annan kärnas L2, sitter den där och taggas som en L3-cache-linje.

Vad IBM har implementerat här är konceptet med delade virtuella cachar som finns i privata fysiska cachar. Det betyder att L2-cachen och L3-cachen blir samma fysiska sak, och att cachen kan innehålla en blandning av L2- och L3-cache-linjer efter behov från alla olika kärnor beroende på arbetsbelastningen. Detta blir viktigt för molntjänster (ja, IBM erbjuder IBM Z i sitt moln) där hyresgäster inte behöver en full CPU, eller för arbetsbelastningar som inte skalas exakt över kärnorna.

Detta innebär att hela chippet, med åtta privata 32 MB L2-cacher, också kan anses ha en 256 MB delad “virtuell” L3-cache. I det här fallet, överväg motsvarigheten för konsumentutrymmet: AMD:s Zen 3-chiplet har åtta kärnor och 32 MB L3-cache, och endast 512 KB privat L2-cache per kärna. Om den implementerade ett större L2/virtuellt L3-schema som IBM, skulle vi sluta med 4,5 MB privat L2-cache per kärna, eller 36 MB delad virtuell L3 per chiplet.

Detta IBM Z-schema har den lyckliga fördelen att om en kärna bara råkar behöva data som finns i virtuell L3, och den virtuella L3-linjen bara råkar vara i sin privata L2, så är latensen för 19 cykler mycket lägre än vad en delad fysisk L3-cache skulle vara (~35-55 cykel). Men vad som är mer troligt är att den virtuella L3-cache-linjen som behövs finns i L2-cachen i en annan kärna, vilket IBM säger har en fördröjning på i genomsnitt 12 nanosekunder över dess dubbelriktade ringinterconnect, som har en bandbredd på 320 GB/s. 12 nanosekunder vid 5,2 GHz är ~62 cykler, vilket kommer att vara långsammare än en fysisk L3-cache, men den större L2 borde innebära mindre tryck på L3-användning. Men också eftersom storleken på L2 och L3 är så flexibla och stora, beroende på arbetsbelastningen, bör den totala latensen vara lägre och arbetsbelastningens omfattning ökas.

Men det stannar inte där. Vi måste gå djupare.

För IBM Telum har vi två chips i ett paket, fyra paket i en enhet, fyra enheter i ett system, för totalt 32 chips och 256 kärnor. Istället för att ha det externa L4-cache-chippet går IBM ett steg längre och möjliggör att varje privat L2-cache också kan hysa motsvarande en virtuell L4.

Detta betyder att om en cache-linje kastas från den virtuella L3 på ett chip, kommer den att hitta ett annat chip i systemet att leva på och markeras som en virtuell L4-cache-linje.

Detta innebär att ur ett enskilt kärnperspektiv, i ett 256 kärnsystem, har den tillgång till:

  • 32 MB privat L2-cache (19-cyklers latens)
  • 256 MB on-chip delad virtuell L3-cache (+12ns latens)
  • 8192 MB / 8 GB off-chip delad virtuell L4-cache (+? latens)

Tekniskt sett från ett enstaka kärnperspektiv borde dessa siffror förmodligen vara 32 MB / 224 MB / 7936 MB eftersom en enda kärna inte kommer att vräka en L2-linje till sin egen L2 och märka den som L3, och så vidare.

IBM uppger att med detta virtuella cachesystem finns det motsvarande 1,5 gånger mer cache per kärna än IBM z15, men också förbättrade genomsnittliga latenser för dataåtkomst. Totalt sett hävdar IBM en prestandaförbättring per socket på >40 %. Andra benchmarks är inte tillgängliga för närvarande.

Hur är detta möjligt?

Magi. Ärligt talat, första gången jag såg det här var jag lite förvånad över vad som faktiskt pågick.

I frågestunden efter sessionen sa Dr. Christian Jacobi (Chief Architect of Z) att systemet är designat för att hålla reda på data om en cachemiss, använder sändningar och minnestillståndsbitar spåras för sändningar till externa chips. Dessa går över hela systemet, och när data kommer in ser den till att den kan användas och bekräftar att alla andra kopior är ogiltiga innan man arbetar med datan. I slackkanalen som en del av evenemanget konstaterade han också att mycket cykelräkning pågår!

Jag kommer att hålla mig till magi.

Sanningen att säga, mycket arbete går åt till något sådant här, och det finns sannolikt fortfarande många överväganden att framföra till IBM om dess funktion, till exempel aktiv kraft, eller om cachar stängs av i viloläge eller till och med utesluts från att acceptera vräkningar helt och hållet för att garantera prestandakonsistens för en enda kärna. Det får mig att tänka på vad som kan vara relevant och möjligt i x86-land, eller till och med med konsumentenheter.

Jag skulle vara försumlig med att prata cacher om jag inte nämnde AMD:s kommande V-cache-teknik, som är inställd på att möjliggöra 96 ​​MB L3-cache per chiplet istället för 32 MB genom att lägga till en vertikalt staplad 64 MB L3-chiplet ovanpå. Men vad skulle det betyda för prestandan om den chipleten inte var L3, utan betraktades som en extra 8 MB L2 per kärna istället, med möjligheten att acceptera virtuella L3-cache-linjer?

Till slut talade jag med några branschkollegor om IBM:s idé om virtuell cachning, med kommentarer som sträckte sig från “det borde inte fungera bra” till “det är komplext” och “om de kan göra det som sagt, det är ganska coolt”.