Såg att de första siffrorna för Tremont (nuvarande Atom, föregångaren till Gracemont som kommer i Alder Lake S). IPC mässigt verkar den ligga på lite över 80 % av Skylake i heltal och strax under 70 % i flyttal.
Då det pratats om 25-30 % högre IPC i Gracemont (det var också ungefärliga lyftet från Goldmont till Tremont) ser det faktiskt ut som de "små" kärnorna i Alder Lake mycket väl kan matcha Skylake i IPC!
Skrivet av anon132576:
Är sånt här som gör att man bara blir så trött på Intel, att de ska hålla på med en massa konstlad produktsegmentering baraföratt av ren girighet.
Det finns massor av varianter av AVX 512 speciellt, och allt sånt här strular till det för både användare och programutvecklare när de gör så här. Star Citizen till exempel startar tydligen inte ens utan AVX; om man kan köpa en ny, modern CPU idag som inte har instruktionsuppsättningen alls så är det faktiskt riktigt jäkla uselt måste jag säga.
Intel kanske tycker att de tjänar mer pengar på att blockera instruktioner som redan finns i processorns kisel, men allt de i slutändan gör är att försämra stödet för senare versioner av AVX speciellt. Om stödet bara finns i ett fåtal processormodeller så saknas incitament att faktiskt använda instruktionerna också även om de kanske skulle gjort nytta.
Hoppas verkligen att AMD gör en fullständig implementation av AVX512 över hela sin produktserie i nästa Ryzen och riktigt fuppar upp Intels fejksegmenterade girighetsvansinne.
Givet att du är fullt medveten om det markerade, känns det då inte som Intel endera har kört helt i ut i spenaten med sin SIMD alternativ så är det något som ändrats rätt fundamentalt på senare tid?
Om programmerare skulle behöva explicit anpassa sina program till AVX-512 via assembler (alt. kompilator-intrinsics, vilket i praktiken är en förenklad variant av assembler) skulle det finns väldigt nära noll program som skulle utnyttja AVX-512 givet hur liten delmängd av marknaden som faktiskt har stöd för detta.
I verkligheten är stödet för AVX-512 nog betydligt mer använt än de flesta skulle gissa, så vad är orsaken?
SIMD har nu funnits i ~25 år på x86, under 10-15 av dessa användes det väldigt sparsamt just då det i praktiken krävde att man skrev assembler. Under de senaste åren har två stora förändringar skett
Nvidias CUDA har lärt massorna att designa program för SIMD, det är samma grundläggande idéer som gäller för GPGPU som för SIMD på CPU för att nå hög effektivitet, GPUer har högre kapacitet men då hyfsat många problem passar SIMD och samtidigt är latenskänsliga finns en klar poäng med SIMD på CPU också
Nvidias CUDA ramverk visade att med relativt små förändringar i hur programmen skrivs kan man lyfta även detta problem bort från assembler och till C/C++ nivå
Den sista punkten har massor med fördelar och det är huvudförklaring till varför Intel kan komma undan med att AVX-512 är ett lapptäcke av olika extensioner, där det känns nästan lite slumpmässigt vilken CPU-modell som råkar implementera vad.
Men precis som GPUer kan skilja sig rätt mycket, både mellan modeller hos samma tillverkare och än mer mellan tillverkare, och ändå köra samma program har man nu nått dit även för SIMD på CPUer.
För att ta ett "hello-world" nivåexempel. Denna funktion tar två lika långa vektorer och beräknar skalärprodukten.
export uniform float dot_ispc(
uniform float A[],
uniform float B[],
uniform float width)
{
// print("Target width : %\n", TARGET_WIDTH);
uniform float res = 0;
foreach (i = 0 ... width) {
res += reduce_add(A[i] * B[i]);
}
return res;
}
Om man tar bort kommentaren för "print" anropet skulle den variera beroende på om man kör SSE, AVX, AVX-512 eller NEON (Arms variant av SIMD). Faktum är att den kan variera även om man kör säg AVX, då en kompilator översätter detta till assembler öppnar sig en rad nya praktiska möjligheter till optimering. Logiken i koden behöver dock inte ändras alls, den kommer automatiskt att utnyttja de instruktioner man säger till kompilatorn är OK att använda!!
T.ex. kan man välja att köra enklare logik, likt den ovan som i grunden är en multiplikation och en addition per vektor element, "två gånger per var och SIMD-lane" vilket minskar overhead per varv i loopen. Om detta är bra eller dåligt varierar från algoritm till algoritm och även från CPU-modell till CPU-modell, enda som krävs om man använder en kompilator (ISPC i detta fall) är att ändra ett argument till kompilatorn.
OneAPI (som internt använder ISPC) tar det hela ännu ett steg. Där kan samma kod köras på CPU eller GPU, valet kan skjutas upp till körning vilket också inkluderar valet att använda SSE, AVX eller AVX-512!
Väldigt mycket pekar på att Alder Lake inte stödjer AVX-512, detta då Gracement verkar stödja upp till AVX2. Att lägga in AVX-512 i Gracemont skulle vara en rejäl suboptimering, hela poängen med upplägget är att ha högpresterande kärnor som kan använda huvuddelen av strömbudget och kiselbudget, medan de små kärnorna har överlägsen prestanda/W och prestanda/transistor.
Med "modern" användning av SIMD är det en icke-fråga om CPUn råkar ha AVX-512 eller ej, programmen kommer utnyttja AVX-512 om det finns (Sapphire Rapids kommer självklart ha det) och de kommer fungera även fast det inte finns.
Att göra som AMD gjorde i Jaguar och Zen/Zen+, d.v.s. internt implementerade de egentligen bara SSE men det gick ändå att köra AVX instruktioner, kanske verkar "smart". Visst kan man då köra program som använder "nya" instruktioner, men är inte helt ovanligt att effektiviteten per instruktion blir logiskt sett lägre med "bredare" instruktioner vilket kan kompenseras med att de bredare instruktionerna gör mer och körs i stort sätt lika snabbt. Om de i stället "emuleras" i HW kan resultatet bli att programvaran väljer t.ex. AVX som då blir mindre effektivt än att köra SSE då AVX-instruktioner i "emulerade" fallet tar dubbelt så lång tid att köra (totalt sett lägre prestanda om effektivitet per instruktion är lägre för AVX).
Och ju vanligare Arm blir ju sämre idé är det att designa någon programvara direkt i assembler/intrinsics, i alla fall om man inte råkar gilla att spendera massor med resurser på programutveckling.
ISPC används för övrigt redan av spelmotorer, det har varit integrerat i Unreal Engine ett bra tag då det passar perfekt till att optimera saker som fysikberäkningar och animationer.
Skrivet av lastninja:
AVX och AVX2 över hela brädet. Får se hure blir med AVX512, för det lär inte Gracemont få ...vilket kan leda till något liknande som med min 5-kärniga Lakefield CPU.
Det finns idéer kring hur man skulle kunna hantera big.LITTLE designer där de två typer av kärnor stödjer lite olika "extrainstruktioner". I grunden bygger dessa idéer på att om en kärna kör en instruktion den inte stödjer blir det ju en anrop in i OS-kärnan (så fungerar det redan idag), man skulle då kunna lägga till logik i kärnan som analyserar om den instruktionen kan köras av någon annan kärna i systemet. Om svaret är "nej" ska programmet krascha, om svaret är "ja" skulle man rent teoretiskt kunna begränsa det programmet till den delmängden av kärnor som stödjer instruktioner och köra vidare.
Så vitt jag känner till har ingen implementerat ovan utanför experimentstadiet, vilket betyder att big.LITTLE designer kräver att alla CPU-kärnor måste kunna köra samma instruktioner, de kan däremot vara rätt olika effektiva på det. Arm kräver detta i sin big.LITTLE teknik (som sedan ett år tillbaka kallas DynamIQ).
Lakefield är ett testskott, en typisk v1.0 produkt. Den har tyvärr begränsningar som tekniken i sig inte medför. Huvudnumret för Lakefield var ju att få ut något på marknaden (och många spekulerade i att det var en av flera saker Intel primärt designat för att behålla Apple).
Att SMT inte används på den "stora" kärnan måste bara vara en förenkling, den begränsningen är borta i Alder Lake S.
Största bristen i Lakefield är att det bara verkar vara en frekvensdomän över alla CPU-kärnor. Det försämrar huvudpoängen med big.LITTLE en hel del, man vill ju köra latenskritiska saker på stora och högt klockade kärnor då latenskritiska saker tyvärr tendera skala uselt med flera kärnor -> enda möjliga förbättringen är högre enkeltrådprestanda. Har inte Intel fixat detta i Alder Lake S är det en totalflopp, men det kommer vara fixat (Arm har aldrig haft detta problem i sin design).
