Sonys ingenjörer arbetar på optimeringar för Zen-arkitekturen

Så om nu de flesta spel optimeras för detta... från grund. Hur tror ni det påverkar spel på PC?

Personligen tror jag Zen kommer plocka en hel del prestanda som Intel åter måste bruteforcea.

Beror på om spelen till PC kompileras med LLVM/Clang.

Jag som enbart PC-spelare tycker det är alldeles utmärkt att dom börjar gå mot nästa generations konsoler. Det innebär ju alltid att spelen som släpps kliver upp ett steg i grafik och man kan spela ännu bättre på sin PC.

Bästa vore ju förstås att allt bara släpptes för Linux och konsolföretagen helt enkelt bara släppte dedikerade Linuxkonsoler. In a perfect world....

Varför Linux? Det är gratis och ett överlägset operativsystem. Hade använt det till allt om det inte vore för att spel inte finns i samma utsträckning till det. Jag nästan njuter av att måsta jobba för då använder jag Linux.

Skickades från m.sweclockers.com

Eller varför inte PlaystaZen

Går faktiskt att hitta enstaka spel från tiden när Skylake-E lanserades där man ser en viss fördel av 6 kärnor. Problemet med senare E-serie modeller var att de fick fler kärnor men deras frekvens matchade inte senare generationer S-serie.

Visa innehåll

i7-980X spöar i7-2600K, Sandy Bridge har hyfsat mycket bättre IPC jämfört med Nehalem/Westmere

En sak som är väldigt relevant att veta när man pratar om LLVM är att man satsar väldigt mycket på något som kallas auto-vektorisering.

Tekniken som sådan har funnits rätt länge, framförallt i GCC. Men GCC sätt genera kod verkar passa rätt illa för att ta "vanlig" sekventiell skalär kod och lura ut hur den kan utnyttja SIMD. För LLVM accelererade arbetet med denna teknik rejält under 2017 och den kompilatorn genererar förvånasvärt mycket SIMD både på x86 och ARM (har själv jobbat väldigt mycket med LLVM på 64-bitars ARM senaste året, bl.a. jobbat med utveckling av C++11/14/17 standardbibliotek ihop med den kompilatorn).

För att få ett lite smakprov på vad LLVM är kapabel till kring detta, testa följande kod

#include <numeric>
#include <vector>

int foo(std::vector<int>& v)
{
    return std::accumulate(v.begin(), v.end(), 0);
}

int bar(std::vector<int>& v, std::vector<int>& w)
{
    return std::inner_product(v.begin(), v.end(), w.begin(), 0);
}

på Compiler Explorer. Välj t.ex. Clang x86-64 som kompilator och lägg till switcharna "-stdlib=libc++ -O2". De två C++ standardfunktionerna ovan blir helt SIMD-optimerade (med SSE2, lägg till "-stdlib=libc++ -O2 -march=skylake" så blir det AVX kod i stället).

För den som vill se lite vettigt designad assembler, sätt switcharna till "-stdlib=libc++ -O2 -target aarch64-linux-gnu" (samma LLVM kan kompilera för en rad olika CPU-arkitekturer, en annan fördel över i princip alla andra kompilatorer där det krävs en binär per back-end).

Och kanske ännu viktigare: C++17 har till slut gett oss programmerare ett vettigt sätt att tala om för kompilatorn "den här algoritmen uppfyller de krav som ställs på SIMD optimerad kod". Det via göra det möjligt att tagga en kodsnutt som std::parallel_unsequenced_policy.

Varför är detta relevant? Jo, väldigt många saker kan inte parallelliseras över många CPU-kärnor p.g.a. att kostnaden för synkronisering mellan kärnor äter upp vinsten med att använda flera kärnor. SIMD har i princip noll synkroniseringskostnad!

Vidare, om jag kör något över två kärnor kommer de på det stora hela gå dubbelt så fort och dra ungefär dubbelt så mycket ström. Om man kör något via SIMD kommer det typiskt dra ~20-30 % mer ström och ge allt från två till >10 gånger bättre prestanda!

Självklart ska man fortsätta jobba på att kunna utnyttja flera kärnor bättre, men där har vi ändå kommit en bit på vägen. Utanför vetenskapliga beräkningar, kodning av film och några andra specialfall används SIMD idag långt mindre än vad det borde. Den absolut största orsaken är att det fram till 2017 egentligen inte fanns något enkelt sätt att utnyttja det (väldigt få skriver assembler idag, OpenCL kan utnyttja SIMD men det är primärt designat för GPGPU och har onödigt hög overhead för mindre jobb).

Sett till rå CPU-kraft använder man i runda slängar 1-2 % av totala kapaciteten i enkeltrådad skalära kod. Har man 8 kärnor och utnyttjar dessa fullt ut använder man runt 10-20 % av kapaciteten om det handlar om skalär kod. För att nå resten behöver man få ut kraften ur SIMD.

Edit: dock är SIMD mer restriktivt jämfört mer flera kärnor. Är lasten uppgiftsparallell (vilket gäller i princip alla I/O-bundna fall) är SIMD helt fel teknik, är problemet dataparallellt (vilket gäller många beräkningstunga fall) är SIMD ofta väldigt användbart.

LLVM/Clang användas allt mer även på Windows. En stor orsak är att LLVM/Clang har, på Windows, en front-end som är väldigt nära 100 % kompatibel med MSVC++ vilket lett till att ett ökande antal som kör Visual Studio fortsätter med det men byter ut kompilatorn mot LLVM/Clang. (På Linux och MacOS är LLVMs front-end nästan helt kompatibel med GCC).

Varför skulle man då vilja köra LLVM på Windows? Därför att LLVM/Clang nästan alltid har bättre stöd för modern C++ jämfört med MSVC++.

Och kanske än viktigare är att LLVM har en växande skara analysverktyg som tidigare kunde användas via olika plugin, men senaste versionen av VS har faktiskt officiellt stöd direkt från Microsoft för saker som clang-tidy, clang-format, AddressSanitizer, m.m.

Ryktas om att Microsoft har en diskussion internt om de kanske ska dumpa MSVC++ till förmån för LLVM. Möjligen likt Apple, d.v.s. med lite proprietära tillägg, något som är fullt möjligt givet LLVMs licens. Företag gillar LLVM för dess licens, utvecklarna älskar LLVM för det ekosystem av utvecklingsverktyg som skapats med LLVM som bas (kompilatorn är bara ett verktyg av många)!

Finns även rykten om att Intel kanske överger ICC och flyttar över än mer resurser på LLVM (Microsoft, Intel, ARM, Google, m.fl. är alla exempel på företag som idag lägger rätt mycket resurser på LLVM).

Är medveten om AOCC och om den primärt är tänkt för internt bruk kanske det är vettigare. För har inte ens sett någon på nätet som hävdar att de använder AOCC och prestandamässigt är det ofta minst lika bra att köra senaste LLVM jämfört med AOCC (som typiskt ligger en/två versioner efter) även på AMD.

LLVM/Clang har stöd för Nvidias, AMDs och Intels GPUer (får nog ändå ses som lite beta-stämpel just nu, men viktigaste är ju att det går framåt)! Det kan bli riktigt trevligt och är nog precis vad GPGPU-tekniken är i kraftigt behov av för att de ska rulla på lite mer.

Lite intressant att LLVM/Clang vektoriserar rätt olika om man använder -march=znver1 jämfört med t.ex. -march=bdver4 (Excavator). Just FPU-delen är på hög nivå rätt lika på Zen och Bulldozer. Alla CPUer från AMD/Intel sedan Bulldozer/SandyBridge stödjer AVX men -march=znver1 genererar nästan uteslutande SSE kod (blir i princip exakt samma assembler som för Nehalem/Westmere). Det medan Bulldozer/SandyBridge och senare genererar AVX om möjligt

(AVX är mer än bara 256-bitars instruktioner, AVX tillåter 128 och 256-bitars operationer med tre operander medan SSE endast ger två operander så man skriver alltid över ett input-argument -> inte vad kompilatordesigners vill se).

I teoretisk kapacitet är det ingen skillnad mellan att använda SSE/AVX på Jaguar, Bulldozer-serien och Zen. Men rent praktiskt borde ändå AVX ge lite bättre prestanda då det belastar avkodningsteget mindre. Något står inte helt rätt till med Zen på denna punkt, har kör ett hel del på min Ryzen och sett att man typiskt får några procent lägre prestanda med AVX jämfört med SSE (men handlar om enstaka procent, så ingen katastrof). Jaguar ser det mer förväntade, d.v.s. någon enstaka procent högre prestanda.

Intel ser nära nog dubbel prestanda med AVX (i det som är AVX optimerat, man ska inte på något sätt vänta sig att totalprestanda blir dubbelt så hög utanför saker som matrisberäkningar och liknande). Blir inte riktigt dubbelt då klockfrekvensen normalt sjunker med AVX + fallen när man inte fullt ut kan nyttja SIMD ökar ju ju "bredare" instruktioner man använder.

Det stora problemet för de som skriver kompilatorer är ju bakåtkompatibilitet. Majoriteten av alla program kompileras än idag endast med SSE2 stöd (vilket är minikravet för x86_64, men det är Pentium 4 nivå!).

En av de få undantagen är "Clear Linux" där minikravet är Nehalem, d.v.s. SSE4.2. I vissa program ser man ingen större skillnad, men finns rätt många exempel där man ser 30 % prestandavinst bara genom att låta dagens kompilatorer utnyttja lite mer moderna instruktioner.

I Linux har man ändå lite nytta av sin moderna dator. C-biblioteket använder t.ex. alltid SSE3 för att accelerera strängoperationer om man har en tillräckligt ny CPU (detekteras dynamiskt vid boot). Till och med finesser som TSX-NI används på Linux (av pthreads) om det finns stöd. Rätt mycket sämre ställt med det på Windows