Intel visar Xe-grafik för datacenter – får Threadripper att se liten ut

Det var ingen dålig krets det där.. MEN! Är det inte @Kenneth som är "Baap of All" (Ba baap) ?
Dags att skicka juristerna på Intel!

Det lär väl snarare vara en konkurrent till AMD Radeon Instinct och NVIDIA Tesla? Radeon Pro och Quadro är ju workstation-kort, inte serverkort.

@perost: Xe-HP riktas mot både workstation och lättare HPC, medan Xe-HPC riktas mot just Radeon Instinct och Tesla. Jag misstänker att Xe-HP kommer göra avstamp i flera av AMD:s och Nvidias produktserier.

Den är stor för att den är i 14nm

Du kör quadro i server med

Du ska se det som ännu ett försök från Intel att övertyga marknaden om att de har något nytt och stort på gång.
Multi-chip Module (MCM) är samma typ av teknik som AMD använt under en tid och som man kallar för chiplet-design.

Ska man vara lite elak så är det här yttersta beviset på att Intel nu överger sin gamla Core-arkitektur och satsar på det de innan kallade för "hoplimmade kretsar". Tydligen visade sig 7nm och "lim" vara framtiden – även för Intel.

Visst, men de marknadsförs som workstation-kort.

Intel har en mycket längre historia med limmade kretsar än AMD. Pentium D var t.ex. två limmade kretsar, och nuvarande Cascade Lake-AP även så.

Det var aldrig själva "limmet" som var problemet med första generationen Epyc, utan att sättet som AMD implementerade det på ledde till inkonsekvent prestanda (samma problem som Pentium D hade mer än 20 år tidigare). AMD har jobbat mycket på just den biten och förbättrat efterkommande generationer avsevärt på det området.

Nu har jag ingen statistik på det, men Quadro-kort är ju väldigt vanliga i både stationära och bärbara workstation-datorer. Jag har svårt att se att NVIDIA säljer mer Quadro-kort för serveranvändning eftersom det då mest handlar om de dyrare modellerna (RTX Server har t.ex. stöd för RTX 6000 och 8000, så minst 50-60k per kort).

Men visst, vill du räkna Quadro som serverkort så får du väl göra det. Det förändrar inte faktumet att Tesla är deras renodlade serverkort.

Xeon är en väldigt bred familj processorer som riktar sig mot både workstation, server och embedded. Eller vad räknar du som Intels serverprocessorer?

Inte sant, detta är exakt vad det hela refererande till

Två saker var klantigt från Intels sidan med detta: användningen av ordet "desktop die" samt egentligen att överhuvudtaget påpeka just detta då just det problemen var redan något tester noterat och tagit upp som nackdel.

Intel har använt MCM väldigt länge, Pentium D är redan nämnt, Core2Quad är ett annat. Men framförallt är varenda U/Y-serie CPU som Intel tillverkar en MCM. Man har ju också patent på ett "superlim" i form av EMIB, en teknik som lär användas i kretsen i artikeln.

Denna slide nämner dock något som är långt viktigare än rå kretsprestanda:ekosystem. Det är huvudorsaken till varför Nvidia totalt dominerar GPGPU-marknaden, fram till nu har inget kommit nära CUDA i enkelhet och kvalité kring programutveckling. Jensen har sagt vad han anser om Intels oneAPI.

Efter att börja testat oneAPI förstår jag varför Nvidia gör precis som Intel gjorde mot Epyc; väldigt mycket tyder på att Intel faktiskt fått till något som på flera sätt är enklare att använda än CUDA!

För GPGPU-delen bygger oneAPI på en öppen standard som kallas SyCL. SyCL togs initialt fram av ett företag som heter CodePlay, av experter på heterogena system och experter på C++. Kombinationen är kritiskt här, för vad man (till skillnad från OpenCL) lyckats med är att ta fram en teknik som

• är enkelt för kompilatorer att optimera, i SyCL beskrivs databeroenden mellan de olika delarna på ett sätt som kompilatorn kan utnyttja till att göra optimeringar (både OpenCL och CUDA saknar detta, motsvarande optimering måste göras manuellt). Mycket av de som görs här kommer av forskning kring kompilatorteknik, mesta av dessa idéer är idag realiserade i LLVM, vilket också är tekniken Intel bygger oneAPI på

• SyCL hittar inte på egna tekniker, utan man använder standard "modern" C++ (C++11 och senare), "one" delen i oneAPI refererar till att exakt samma C++ kan köras CPU, GPU eller FGPA. Allt kompileras för varje acceleratortyp och därmed optimeras separat, men beskrivningen (i.e. källkoden) är densamma för alla.

• Precis som CUDA, och till skillnad från OpenCL, skriver man GPGPU-koden och CPU-koden i samma fil. Det förenklar överblicken då man kan lägga saker där de logiskt hör hemma

oneAPI kör en utökad variant av SyCL, men Intel jobbar på att få in alla utökningar i nästa version av SyCL (som hanteras av samma organisation som hantera Vulkan, OpenGL, OpenCL, m.fl. Khronos). Även här har man undvikit "not invented here" syndromet. Tilläggen kommer från finesser i 2020 års ISO C++ standard (är klart att de kommer, men C++20 är inte formellt lanserad än), så även dessa passar perfekt in i "vanlig" C++ kod.

Ovanpå det har Intel lagt väldigt mycket krut på att integrera deras MKL (Math Kernel Library, ett bibliotek som används väldigt mycket på HPC, neuronnätverk och program som Matlab). Det är också ett genidrag (om det nu fungerar, denna del har jag inte hunnit testa). MKL används mycket, men det har fram till nu varit CPU-only. Genom oneAPI kan man köra samma saker på GPU, det betyder att t.ex. Matlab och TensorFlow kan använda Intels GPU (är här AMD/Intel/alla-förutom-Nvidia tidigare misslyckats p.g.a. undermåligt programvarustöd).

Resultatet av det kommer bli att Tiger Lake och andra som kör Xe (Rocket Lake?) kommer nå en helt ny prestandanivå i de program som använder MKL, vilket är många program inom forskning och simulering. Detta är ett område som tidigare i praktiken bara fungerade på GPUer via CUDA och CPUer via MKL (med MKL används SSE/AVX/AVX-512, fungerar så klart på CPU utan detta men då med långt sämre prestanda)!

En sak som går i teorin, men är väldigt bökigt i praktiken med CUDA, är att parallellt använda CPU+GPU för att lösa samma problem. Det är p.g.a. oneAPIs design väldigt enkelt där, något som kan visa sig bli väldigt värdefullt på bärbara med begränsade resurser. Detta är egentligen exakt vad AMD siktade på med köpet av ATI, i.e. det var tanken med "fusion". Problemet där har alltid varit att man så här långt inte fått fram en vettig programmeringsmodell. Möjligen kan Raja Koduri få till sin vision denna gång...