Intel tillkännager Cascade Lake-AP med upp till 48 kärnor och tolv minneskanaler

mpat har rätt.
Pentium D var före.
Anledningen att fler Tänker på Core 2 Quad (som var dubbla Core 2 Duo chip) är att Core 2 Quad var en ganska lyckad och populär produkt. Medan Pentium D inte blev lika populär.
Man ja både Core 2 Quad och Pentium D "använde lim".

Ska man göra en 2 kärnig processor så är helt klart en monolitisk design bättre än "att limma".
Men pratar vi stora 30+ kärnor processorer så blir det svårt att få någon vettig yeild om man ska använda en monolitisk design. I en mångkärnig processor blir det också svårare att få till att alla kärnor ska ha snabb kommunikation med alla andra kärnor, allt minne, etc än i en få-kärnig processor. Så det är sannolikt att man ändå får göra kompromisser som gör att det inte blir lika stora fördelar att hålla sig till en monolitisk design.

Så det kan mycket väl vara ett smart drag av Intel och de får säkert kunder som köper dem.

Det ironiska är att Intel klagar på AMD för att Ryzen Threadripper och Epyc "använder lim"
Sen börjar de själva använda det.

Oavsett vad man har för åsikter om Intel och AMD, vilket som är ens favoritmärke (om man har ett), vad för dator(er) man har. Så behöver man inte vara ett stort fan av hyckleri.

Så vitt jag kan minnas har Intel alltid varit större än AMD. Tycker det är lite tråkigt att det känner ett behov av att ta till cheap shots när de ändå är Goliat.

"Ihop-limmande desktop kretsar" var ett rätt korkat uttalande från Intel då det är just bara den delen av det hela medellandet som majoriteten idag känner till. Den relevanta delen av uttalande faller konsekvent bort.

Hela uttalandet var

"Inconsistent performance from 4 glued together desktop dies"

Den inledande delen är vad man rimligen ville få fram då det gör designen olämplig för en rad tillämpningar. Den inledande delen är också något som andra verifierat är fallet.

Det borde inte ha förvånat något givet att exakt samma problem gäller även för Intel multi-socket system, av exakt samma anledning.

För OSet är en Skylake SP krets verkligen en CPU med en 6-kanals minneskontroller och en PCIe kontroller med 48 kanaler.

En Epyc CPU är för OSet fyra stycken 8-kärniga CPUer med fyra 2-kanals minneskontroller och fyra PCIe kontroller med 32-kanaler var, där alla kretsar har en direktlänk mellan sig

Ett quad-socket Skylake SP är för OSet fyra stycket 4-28 kärninga CPUer med fyra 6-kanals minneskontroller och fyra PCIe kontrollers med 48-kanaler var.

En Cascade Lake AP, som av den läckta informationen verkar primärt riktad mot HPC marknaden som ersätter för Xeon Phi (som Intel har lagt ned), lär ur alla praktiska aspekter därför vara identiskt med ett dual-socket Cascade Lake SP system. Enda fördelen med att stoppa in två kretsar i samma paket är att det tar mindre plats, ur OS och applikationsperspektivet är dual socket Cascade Lake SP och single-socket Cascade Lake AP identiskt (möjligen kan man trimma latens och bandbredd mellan kretsar on-package).

Latensen på limmade kretsar blir självklart rejält mycket sämre jämfört med latensen inom en monolitisk krets. Men "worst-case" i detta fall är att Intel kör UPI rakt av mellan kärnorna och överhuvudtaget inte utnyttjar att ett väsentligt kortare avstånd kan utan större problem användas till att minska latens samt öka bandbredd (d.v.s. helt enkelt höja frekvensen på UPI-bussen on package)

UPI på Skylake SP har mer eller mindre identisk latens och bandbredd mellan sockets som Epyc har mellan chiplets on-package. Länk.

Hur det är bra eller dåligt lämnar jag till var och en att avgöra.

Primära orsaken till att SMT uppfanns var för att ha ett väldigt effektivt sätt att "gömma" latens.

Har funnits CPUer med både två och fyra kärnor per CPU som bara varit kapabla att köra en till två instruktioner per cykel. Varför skulle man vilja ha SMT där???

Tja, om man får en cache-miss så kan lätt ta >100 cykler innan CPUn får den informationen man behöver. Har man då flera CPU-trådar per kärna så kan man ju göra vettig arbete så länge minst en tråd har den informationen den behöver.

Tittar man specifikt på x86 finns ytterligare anledningar: x86 är en rent ut sagt horribel design om man vill designa en riktigt bred back-end. Primärt av två anledningar

• x86 tillåter extremt lite flexibilitet när det kommer till hur CPUn får ändra ordning på läsningar och skrivningar mot RAM. Detta är en effekt av att man specificerade detta i en tid innan multi-core var vanligt samt vid en tid när RAM var långt snabbare i förhållande till CPU-hastigheten jämfört med idag. ARM, PowerPC och i princip alla RISC förutom SPARC har en modell här som tillåter långt mer flexibilitet för CPUn att hantera minnesoperationer

• en väldigt stor andel av x86 instruktioner påverkar en global resurs, status-registret. För alla som kan något alls om multi-core programmering, det är som att ha flera trådar läsa/skriva till samma minnesadress -> horribel skalning. Många CPU-designer lider av detta, undantagen är 64-bitars ARM samt RISC-V där majoriteten av alla instruktioner bara påverkar de register som är utdata

SMT hjälper båda dessa fall då två separata trådar i de flesta fall kan hantera sina minnesoperationer helt oberoende av varandra samt varje CPU-tråd har en egen uppsättning av alla register så med två trådar dubblar man i praktiken skalbarheten m.a.p konstant modifiering av en, mellan instruktioner i samma instruktionsström, delad global resurs.

Ovan ger en vink om varför Apple kan designa en 64-bitars ARM CPU som kan processa 7 instruktioner per cykel och faktiskt dra rejäl nytta av det (IPC runt 50 % högre jämfört med Skylake) medan Skylake/Zen har grava problem att processa 4-5 instruktioner per cykel även med SMT.

Finns monolitiska kretsar tillverkade på TSMC 40 nm med 72 kärnor. Mer nutida design har ju Cavium en 32C/128T krets på TSMC 16 nm samt Intels Xeon Phi med 72C/228T tillverkad på Intel 14 nm.

Är definitivt enklare att tillverka ett gäng mindre kretsar och "limma ihop dem". Problemet är att bara en relativt liten delmängd av de problem som datorer används för att lösa skalar något vidare över flera kretsar av dessa orsaker

• inom en monolitisk krets är latensen mellan kärnor ungefär en tiopotens lägre än det bästa vi idag har mellan kretsar

• inom en monolitiskt krets är bandbredd en till två tiopotenser högre jämfört med vad som är ekonomiskt rimligt att få mellan kretsar (detta har mer med ekonomi än teknik att göra, bandbredd är till skillnad från latens ett "lätt" problem att skala)

Ett till problem som drabbar SMT upptäcktes i dagarna. Ingen verkar ha några större förhoppningar att det kommer gå att fixa då det rätt mycket utnyttjar det faktum att CPU-trådar i en SMT design delar exekveringsportar.

"The only way to mitigate this attack is to disable SMT/Hyper-threading on a computer, which OpenBSD has already done by default since this summer when another timing attack was released called TLBleed."

Helt korrekt. Redan innan Spectre/Meltdown fanns en del kända s.k. "side-channel attacks" mot kretsar med SMT, men verkar som i jakten på Spectre/Meltdown relaterade problem har man även lyckats skaka ut en hel del SMT-relaterade problem.

Problemet med spekulativ exekvering är: vi lär bara ser mer och mer av detta då det är enda kända sättet att på något sätt öka mängden arbete en CPU kan utföra per cykel.

Den snabbaste CPU-designen som finns utan att spekulativ körning används är ARM Cortex A55. Den utför mindre än hälften så mycket per cykel som dagens "big-core" x86 CPUer (som i sin tyr "bara" utför ~75 % av Apples senaste 64-bitars ARM per cykel).

Vi får förhoppningsvis veta mer om Rome imorgon.

Men att ingen gjort den rätt uppenbara observationen i denna bild

Låt oss nu kalla kopplingen mellan "compute cores" och den stora kretsen i mitten för "front-side bus" samt kalla den stora kretsen i mitten för "north-bridge". Någon som känner igen designen?

Detta är exakt vad Intel gjorde med Pentium D och Core2Quad, d.v.s. flera "limmade" CPU-kretsar som man delar samma minneskontroller så man fortfarande bara får en NUMA-zon per sockel (och som lök på laxen får man då också en homogen PCIe hantering per socket och inte en väldigt asymmetrisk sådan som man för med I/O-delen lokalt i varje CPU-krets).

Hoppas verkligen ryktet kring detta är sant, för designen man hade med nuvarande Epyc har exakt samma problem man hade med Magny-Cours Opteron och av exakt samma själ då som nu leder det till en design som bara fungerar inom en rätt smal nisch.

Givet Intels problem med 10 nm, givet att de har kapacitetsproblem med 14 nm och givet att 64-bitars ARM än så långe inte stampat x86 till småbitar i datacenter (det kommer hända, frågan är bara när) så är enda rimliga förklaringen till att Epyc förfarande har <2 % marknadsandel Q3 2018 just att designen hindrar dem från att ersätta Xeon i majoriteten av användarfallen.

Intels quad- och octa-socket system används också i väldigt få fall. Det är inte enbart en prisfråga, faktum är att ett quad-system blir billigare jämfört med ett dual-socket system om man matchar antalet CPU-kärnor i båda (plus att det då går att klocka CPUer i quad-systemet högre). Men antalet applikationer som fungerar bra med ens två NUMA-zoner är få och de som fungerar bra med fyra NUMA-zoner är en riktigt liten nisch.

Mellan 2016 och 2018 har man tappat marknadsandelar om man ska tro den grafen medan AMD har ökat under denna tid. Så jodå..

Nästan lika roligt som att se folk slänga epitet runt sig för folk gillar utveckling. För att det ska bli något annat än monopol så är det bara bra för marknaden att det går bra för AMD så det jämnar ut sig.. men alltid ska det finnas folk som skriker fanboys bara för att man som neutral gillar att det går bra för en part så den dominerande parten tvingas utveckla igen.

Men visst är det enklare att skrika fanboy än att sätta sig in i VARFÖR folk gillar vad de ser.

Om man verkligen gillar utveckling bör man hålla tummar för att det går käpprätt åt fanders för både Intel och AMD. För just nu är x86 en rejäl bromskloss för utveckling, både på server och desktop.

Är relativt nyligen som man inom programmeringsvärlden kunnat formalisera saker som hur olika CPU-trådar bör "se" skrivningar utförda av andra CPU-trådar.

Inte fullt lika nyligen som man slog i ett hårt tak i hur mycket det går att skriva upp frekvens.

x86 är allt annat än en optimal design vare sig för att hantera hur C++, Java, C# m.fl. specificerat sitt beteende i multitrådade applikationer. 64-bitars ARM (men INTE 32-bitars ARM) samt något som kallas RISC-V (som till skillnad från ARM är en helt öppen/fri specifikation) är specifikt designade för att vara en perfekt match för vad de populära programspråken vi ha i detta fall. En konsekvens att båda dessa CPU-designer lanserades första gången 2011, vilket var sent nog för att alla ovan nämna språk skulle ha färdigställt specifikationen för multitrådade applikationer (de är extremt snarlika i sin specifikation, C++ är klart mer flexibel och ARM64/RISC-V stödjer alla varianter perfekt).

När det inte går att skruva upp frekvens är enda vägen till högre enkeltrådprestanda (som är och lär förbli extremt viktigt för både servers och än mer desktop) att designa allt "bredare" CPU-kärnor. x86 är horribel ur flera aspekter här.

Att AMD/Intel ens lyckas avkoda upp till 4-5 instruktioner per cykel är ren ingenjörsmagi. x86 instruktioner kan vara från 1 byte till 15 bytes, enda sättet att veta när nästa instruktion börjar är att först lura ut hur lång framförvarande instruktion är.

Lite enklare för Apple att kunna avkoda upp till 7 instruktioner när alla instruktioner är 4 bytes långa...

Alla CPUer har ett globalt tillstånd associerade med varje CPU-tråd. x86 (och i princip alla CPUer som är äldre än 10 år med möjligt undantag för PowerPC) tenderar att väldigt frekvent modifiera detta globala tillstånd, något som försvårar designen av en riktigt bred "back-end" då man även måste gissa hur detta globala tillstånd ändras för att kunna göra lyckad spekulativ körning. 64-bitars ARM och RISC-V är specifikt designade för att så sällan som möjligt modifiera globala tillstånd, vilket gör en riktigt fet back-end betydligt enklare att designa.

Tyvärr lär byte till någon annat än x86 på skrivbordet ta väldigt lång tid. Det lär gå fortare på server-sidan, men kommer ändå vara en smärtsamt seg process. Detta hade faktiskt gått fortare om Intel helt saknat konkurrens på x86 då företag hatar "single source" (och nej, Intel hade inte blivit uppdelade i det läget givet att det säljs mer än tio ARM CPUer per x86), även om fast majoriteten i slutändan ändå köper från en och samma tillverkare.

Förlåt att jag vilt hoppar in i eran diskussion, men eftersom ni pratar om SMT kunde jag inte låta bli...
Det finns rykten, och jag medger att de ska tas med en stor nypa salt, att denna nya Intel cpu har SMT avstängt för att hålla nere tdp. Detta förklarar i så fall också varför, om man läser det finstilta i Intel's presentation, deras prestanda claims är gentemot en AMD Epyc med SMT avstängd...

That's right.
Cascade Lake år 2019, kommer enligt Intel's finstilta configurations-spec i slutet av dessa presentations slides, vara snabbare än en AMD cpu från mitten av 2017 med SMT avstängt.

Känns det redan chockerande dåligt eller som extremt osmakligt fulspel så fortsätt hålla hårt i foliehatten:
Fortsätter man läsa det finstilta så testade de inte mot sin egen cpu på riktigt, utan bara mot "Advanced processor projections" av hur de förväntar sig att deras nya cpu borde prestera. De har alltså testat en current-gen AMD 32-core Epyc med SMT avstängt mot hur de gissar att deras kommande 48-core processor kommer prestera.... och säger att de "vinner" i prestanda med 70%.

Med SMT så har denna cpu 96 trådar.
Att 96 trådar Cascade Lake bara vinner med 70% mot 32 trådar Epyc är för dåligt för att vara sant, så antingen har Cascade Lake inte SMT alls eller kanske mer troligt om vi ignorerar ryktena så hade den också SMT avstängt.
Fortfarande stirrar vi då på ett scenario där 50% fler trådar ger 70% prestanda mot en gammal Epyc (+13% tråd-för-tråd).
Samtidigt vet vi att kommande Epyc Rome - enligt faktisk fysisk sampling av tidiga testexemplar och inte någon "Advanced projection" spekulation - även den presterar minst 70% bättre än samma Epyc cpu som Intel testade mot - och det på ett testexemplar som inte hade fullt fungerande minneskontroller...

Redan där kan vi konstatera att Intel har förlorat striden om prestandan, but it gets worse:
Epyc Rome väntas kosta mindre än Intel's 28-core kostar idag.

Låt mig formulera det enkelt... Intel Cascading Bullshit Lake.
Jag orkar inte låtsas som att jag inte formligen vadar mig fram i Intel PR-bullshit ända sedan AMD lanserade Zen.
Det enda Intel "vinner" är en BS Award och deras kommande processor är det som flyter i deras konstgjorda BS-sjö.
Jag tror de flesta kan lista ut vilket ord jag fiskar efter där.

@Yoshman: Jo, ironin i att framtiden går "tillbaka" till en design som påminner om svunna tiders nordbryggor är inte förlorad på mig.

Finns flera anledningar.
1. Den viktigaste torde vara att det är väldigt få typer av arbetsuppgifter som vinner på att ha ännu fler trådar per kärna, samtidigt ökas overhead så att alla andra program går jämförelsevis långsammare. Med två trådar per kärna kan man vinna prestanda utan att tappa när flertrådigt inte hjälper.

2. Detta är ett argument att inte alls använda SMT.

3. Inaktiverat HT för att hålla ner TDP verkar rimligt, eftersom HT ökar kärnornas belastning och denna CPU redan lär dra mer effekt än önskvärt. Det är även en metod att stoppa sårbarheten som nämns ovan.
Däremot ska man vara observant på att i Intels jämförelse mot Epyc används också ett benchmark som ska köras utan SMT. Epyc hade fått sämre resultat med SMT aktivt. Säger alltså inte rakt ut att den nya Xeon inte kan använda HT...

Jim har som vanligt en intressant och djuplodande analys...

I de flesta fall ger SMT ett positivt tillskott av prestanda, i alla fall så länge man har 2-4 trådar per CPU.

Finns två primära nackdelar med tekniken

• cache-storlek per tråd minskar då trådarna måste dela på den resursen

• prestanda per CPU-tråd minskar vilket kan leda till höga svarstider eller hög varians i svarstider

Den första punkten är orsaken till varför man i princip alltid slår av SMT i SIMD-optimerade algoritmer. Med rätt gjord SIMD-optimering får man så hög kapacitet att bandbredd blir primär flaskhals, att då minska cachen sett per tråd har i flera fall en större negativ effekt jämfört med den vinst man får med SMT.

Cache-effekten blir ju större ju fler trådar man har per kärna, SMT-8 är därför bara en fördel i applikationer där "working-set" ändå är så stort att cachen inte tillför så mycket (finns absolut sådana laster på servers, men de är inte supervanliga).

POWER8 har stöd för SMT-8, men normalfallet är att man konfigurerar dessa system med SMT-4.

Den andra fallet blir ju också mer uttalat ju fler trådar man har. Svarstiden kan dock bli lägre med SMT om servern hanterar väldigt många fler sessions än den har CPU-kärnor och sessionerna kräver mycket CPU. Så här är det väldigt mycket från fall till fall.

I just fallet Cascade Lake AP verkar den plattformen inte vara en generell serverplattform om man kikar på presentationerna. Det verkar vara en plattform specifikt inriktad på HPC (Linpack) och maskininlärning (inferens steget). Detta är typexempel på sådant där man normalt stänger av SMT, så är ju inte omöjligt att Cascade Lake AP är en relativt nischad produkt mot dessa områden vilket i så fall inte alls gör det osannolikt att den saknar SMT stöd.

Du kan inte bara säga "ARM", att jämföra 32-bitars ARM med 64-bitars ARM är rätt mycket som att jämföra x86 med SPARC.

SPARC och x86 har samma minneskonsistensmodell (båda kör med något som kallas TSO, lätt för människor att förstå men allt annat än optimalt ur optimeringssynpunkt), båda ser stor nytta av SMT men är väl någonstans där de stora likheterna.

32-bitars ARM är på många sätt en lika horribel instruktionsuppsättning som x86. T.ex. så är i princip alla instruktioner villkorade på tillståndet hos statusregistret. Vem f-n tyckte det var en bra ide? Fanns säkert fördelar sent 80-tal / tidigt 90-tal om man siktade på mikrokontrollers, men en sådan design gör det rätt svårt att designa något med riktigt högt IPC.

Finns en rad andra designmissar i 32-bitars ARM, överhuvudtaget är 32-bitars ARM ett lysande exempel på att RISC/CISC uppdelningen är meningslös. Tror nog alla klassar 32-bitars ARM som "RISC", men den har massor med riktigt komplicerade instruktioner, finns en instruktion som kan spara/ladda godtyckligt antal register till/från stacken och den måste i praktiken mikrokodas (och är en instruktion som används väldigt mycket...).

64-bitars ARM är en helt ny instruktionsuppsättning, man har samma minneskonsistensmodell som 32-bitars ARM (då den modellen är både strömsnål och ger väldigt mycket utrymme för optimeringar på multicore CPUer). Däremot är formatet på instruktioner helt annorlunda, bara de instruktioner man förväntar sig vara villkorade är nu villkorade medan majoriteten är opåverkade samt påverkar inte själv statusregister (vissa instruktioner finns i två varianter, en som påverkar statusregister och en som inte gör det).

Går man in lite mer på detaljer så ser man också att det egentligen bara är de CPU-modeller som enbart stödjer 64-bitars ARM som presterar riktigt bra, rätt säker att förklaringen ligger rätt mycket i att man under en övergångsperiod var tvungen att stödja båda instruktionsuppsättningarna och då kunde man inte heller riktigt nå (och numera klå) x86 prestanda.

Apples riktigt snabba modeller är enbart 64-bit, ARMs första "desktop-class" krets (deras egna ord) är Cortex A76 som också är deras första rena 64-bitars krets.

Om du fortfarande är skeptiskt. Titta vad Crays nuvarande top-of-the-line produkt använder för CPU, det är Cavium Thunder X2 (som naturligtvis är en ren 64-bitars ARM).

Kan hålla med om "intressant", inte lika övertygad om "djuplodande".

Karln måste ju ha något personligt agg mot Intel.

Han kallar Cooper Lake för "två ihop-packade Skylake SP kretsar". Hade hade läst det material som visas i hans egen video borde han noterat att redan Cascade Lake är en delvis ny krets då den stödjer funktioner som Skylake SP saknar (detta finns i Intels officiella dokumentation för deras CPUer). Vidare stödjer Cascade Lake Optane memory (vilket var nyheten som presenterades, precis som nämns lanserades själva minneskretsarna tidigare i år).

Självklart finns möjligheten att Copper Lake aldrig släpps, men om den släpps är det redan känt att även etta är en krets med nya funktioner, som stöd för ett relativt nytt flyttalsformat som är tänkt för maskininlärning.

Fast hade han läst på de slides han visar i videon borde ju han inte säga "impossible to believe". Något som nämns är att Cascade Lake får stöd för något som kallas VNNI (som också det är beskrivet i den officiella dokumentationen för Intels CPUer).

VNNI är i princip HW-acceleration av "DL inference", så x17 i en CPU som består av två kretsar + får VNNI är rätt mycket vad man bör förvänta sig om man kollar vad VNNI faktiskt gör.

Givet design av Cascade Lake AP (framförallt om den saknar SMT) pekar ju på att det är en produkt nischad mot HPC, något som www.top500.com också gissar. D.v.s. det ser inte ut att vara en generell server-krets utan en mer en direkt ersättare för nyligen nedlagda Xeon Phi.