Skrivet av Dinkefing:
Fast nu är ju det Skylake+++ du borde jämföra med inte Skylake första iterationen. Egentligen betvivlar jag inte heller att Intel hade haft ledartröjan nu om de inte varit så bekväma och strulet på tillverkningssidan. Jag håller med om att X86 är en utdöende instruktionsteknik men det betyder inte att ARM kommer få fotfäste inom närmaste framtid förutom på Apples kommande Macbook-serie. Det är Apples processorer som börjar närma sig med IPC inte ARMs (Qualcomm med flera).
Hur tänker du att man ska sätta ditt Apple ARM-processorer i Windows burkar? Och jag förstår inte varför du hoppas på GPGPU? Det är inget som konsumeter har nytta av. Inga grafikkort gjort för konsumenter har GPGPU funktioner och Vega var väl sista grafikkortet som hade det?
Håll isär "IPC" och "prestanda per kärna".
Apples A13 är långt förbi alla x86 vad det gäller utfört arbete per kärna, sett till SPECInt, SPECFp och Geekbench 5 har Apple en ledning på ~80 % i mängd utfört arbete per cykel.
Är inte meningsfullt att direkt jämföra faktiskt IPC i dess tekniska korrekta mening, det p.g.a. vad jag belyser i detta inlägg. En av orsakerna att ARM64 (Aarch64) kan ha ett sådant övertag över x86 i utfört arbete per cykel beror bl.a. på att instruktionsuppsättning är specifikt designade för att vara effektivt för kompilatorer -> att översätta en viss C++, C#, Java, Rust snutt till maskinkod tar ofta färre Aarch64 instruktioner jämfört med x86 instruktioner.
Sett till just utförd mängd arbete per cykel har ARMs Cortex A serie historisk legat rätt långt efter high-end x86. Men efter ARM blev uppköpt av Softbank och avnoterade från börsen har man börjat introducera modeller som inte bara är billiga mer hög perf/W, man har allt mer skruvat upp absolutprestanda. Redan för två år sedan, med Cortex A76, nådde man en nivå där lika mycket arbete utförs per cykel som hos Skylake/Zen2.
Varken Apple eller ARM har gjort designer som kan klockas lika högt som AMD/Intels toppmodeller, så att matcha mängd utför arbete räcker inte för att nå samma absoluta prestanda. Vad som precis lanserats från ARM är Cortex X1, en CPU som verkar specifikt vara framtagen för desktop-användning. Cortex X1 förväntas gå att klocka till 3,0-3,3 GHz och den utför ~60 % mer per cykel jämfört med Skylake/Zen2 i program som är kompilerade "native" för respektive CPU.
DET är en CPU som kommer användas i nästa års Windows baserade ARM-laptops. Problemet är att Intel får ut Tiger Lake redan nu i sommar, den förväntas nå 4,4-4,5 GHz och ha ~25 % högre IPC jämfört med Skylake.
Så Tiger Lake motsvarar en Skylake på 4,5 * 1.25 = 5,6 GHz
Medan Cortex X1 motsvarar en Skylake på 3,3 * 1.6 = 5,3 GHz
Tror inte det räcker, ARM måste nog vara bättre än x86 för det börja hända något rejält på Windows-sidan.
GPGPU
Varför GPGPU? Därför att GPGPU är det enda som kan ge någon relevans till "stark" iGPU. Faktum är att iGPU har flera fördelar över dGPU i just GPGPU. Då CPU och GPU delar RAM är det otroligt låg kostnad att flytta jobba mellan dessa delar, vidare finns ingen begränsning av storlek (även om Pascal och senare har stöd att även utnyttja system RAM krävs att applikationen också använder en tillräckligt modern version av CUDA för att det ska fungera).
AMD pushade något de kallade "Fusion" rätt hårt efter uppköpet av ATI. Tanken har alltid varit helt rätt, vissa saker utförs långt mer effektivt på en GPU så dessa bör därför utföras på en GPU når sådan finns. Att man aldrig kommit någonstans med detta är primärt ett programvaruproblem, AMD har aldrig lyckats skapa någon vettig programeringsmodell för sina GPUer eller APUer.
Nvidia knäckte dGPU delen med CUDA. Enda problemet med CUDA är att det drar upp kostnaden, man måste alltid skriva två versioner. En för GPUer och en för CPUer om man alls vill kunna köra programmet på system som saknar Nvidia GPU.
Intel har nu knäckt den sista delen av detta. Dels har Intel tagit GPGPU-programmering ännu ett litet steg närmare "vanlig" programmering jämfört med CUDA. CUDA är nästan standard C, men bara nästan då man har en del icke-standard utökningar. OneAPI använder helt standard ISO C++20, självklart med extra bibliotek men språkmässigt finns inga icke-standard utökningar.
Ovanpå det blir normalfallet när man skriver mot oneAPI att programmet kommer automatiskt välja om det ska köra på CPU eller GPU. Det kommer föredra GPU, om kompatibel sådan saknas väljs CPU. Och handlar inte bara om att det "fungerar" på CPU, den testning jag gjort så här långt pekar på att det är riktigt effektiv CPU-kod man får. Det betyder att merkostnaden för att nu använda GPGPU är extremt låg.
CUDA används i de fall där man får x10 eller något sådant. D.v.s. vinsten är så stor att det är värt extrakostnaden i utveckling. OneAPI har långt mindre tröskel, finns egentligen ingen anledning att inte använda det så länge det är en nettovinst. Givet förväntad prestanda hos Tiger Lakes GPU lär den prestera minst i nivå med välskriven AVX-kod körandes på en 3950X.
Det sista är tyvärr dåliga nyheter för ARM på Windows, för om mycket prestandakritisk kod hanteras av GPGPU har man ju en "work-around" för att x86 inte är lika effekt som ARM64...